Zusammenfassung

  • RFC 7807 vom März 2016 führte ein gemeinsames JSON- und XML-Format für HTTP-Probleme ein. Die type-URI war schon damals die maßgebliche Kennung für Maschinen.
  • RFC 9457 vom Juli 2023 ersetzte den Vorgänger und beschrieb deutlicher, weshalb relative URIs und spätere Adresswechsel Clients beschädigen können.
  • Das IANA-Register erfasst gemeinsame Problemtypen. Fehlt type, steht about:blank für keine zusätzliche Bedeutung über den HTTP-Status hinaus.

Eine Ablehnung braucht manchmal einen Grund

Der Status 403 ist ein brauchbares Urteil für allgemeine HTTP-Software: Die Anfrage wurde verweigert. Ein Einkaufssystem braucht danach eine feinere Unterscheidung. Fehlendes Guthaben verlangt eine andere Reaktion als ein Verbot durch eine Geschäftsregel. Für jede Geschäftsregel einen eigenen HTTP-Status einzuführen, würde die gemeinsame Sprache des Protokolls auflösen. RFC 7807 teilte die Arbeit auf: Der Status bleibt für die breite Klasse der Antwort zuständig, der Inhalt benennt das Problem der Anwendung.

Im Beispiel des Standards scheitert ein Kauf mit 403. Der Antwortkörper enthält einen Typ für fehlendes Guthaben, einen lesbaren Titel, eine Erklärung des Einzelfalls, dessen instance-Adresse und zusätzliche Angaben zum Kontostand. Das Medienformat application/problem+json ist gemeinsam; XML wurde ebenfalls festgelegt. Was „fehlendes Guthaben“ in einem bestimmten Dienst bedeutet, entscheidet dessen Betreiber. Ein Standard kann die Hülle liefern, aber nicht die Regeln jedes Händlers schreiben.

Für Programme ist type das entscheidende Feld. Bereits RFC 7807 bestimmte die URI zur primären Kennung des Problemtyps. title hilft Menschen und kann übersetzt werden. detail erklärt eine einzelne Situation; Clients sollen aus diesem Fließtext keine Steuerbefehle herauslesen. Wer auf das Wort „Guthaben“ in einer Meldung reagiert, scheitert an der nächsten Textänderung. Wer eine URI erkennt, verlässt sich auf ein präziseres Versprechen des Betreibers.

instance ist ein anderes Versprechen. Es bezeichnet einen Vorfall, während type eine wiedererkennbare Fehlerklasse bezeichnet. Zwei fehlgeschlagene Käufe können denselben Typ und verschiedene Instanzen haben. Eine Supportabteilung sucht den einzelnen Vorgang; ein Client entscheidet anhand des Typs über seine Reaktion. Beides unter „Fehler-ID“ zusammenzufassen verwischt diese Trennung.

Das absichtlich leere Etikett

Ohne angegebenen Typ gilt about:blank. Der Name passt zu seiner engen Aussage: Dem HTTP-Status wird keine weitere Semantik hinzugefügt. Eine 404-Antwort wird durch eine hübsche JSON-Struktur nicht plötzlich zu einer eigenen Fehlerklasse. Soll ein Client einen speziellen Grund erkennen, muss der API-Betreiber ihn benennen, dokumentieren und den Namen erhalten.

Auch das Feld status im Körper ist nur ein Hinweis. Wenn es vorhanden ist, muss es dem wirklichen HTTP-Status der Antwort entsprechen. Ein Vermittler kann Abweichungen hervorrufen; archivierte Inhalte können ihren ursprünglichen Antwortkopf verlieren. Allgemeine HTTP-Software richtet sich dennoch nach dem Status der tatsächlichen Nachricht. Die Problemstruktur ergänzt diese Schicht, sie regiert sie nicht.

2023 kam die Rechnung für schlechte Namen

RFC 9457 übernahm 2023 die Grundstruktur und machte die Kosten einer URI-Wahl deutlicher. Eine relative Angabe wie example-problem wird je nach Basisadresse zu verschiedenen Ressourcen aufgelöst. Gleich aussehende Typwerte können damit verschiedene Identitäten meinen. Deshalb empfiehlt der Nachfolger nach Möglichkeit absolute URIs.

Eine nicht aufrufbare URI ist zulässig. Will der Betreiber später eine dokumentierte, aufrufbare Adresse verwenden, schafft der Austausch allerdings einen neuen Typnamen. Alte Clients erkennen ihn womöglich nicht. Eine beiläufige Benennung wird zur langfristigen Kompatibilitätsfrage. Der Standard behandelt zudem mehrere Fehler: Mehrere ungültige Felder können unter einem Validierungstyp beschrieben werden; treffen unterschiedliche Typen zusammen, soll der wichtigste oder dringendste die Antwort prägen. Eine HTTP-Antwort hat schließlich einen maßgeblichen Status.

Das mit RFC 9457 angelegte IANA-Register gilt für allgemeine, wiederverwendbare Typen und verlangt eine Spezifikation. Anwendungsinterne Namen bleiben bei den jeweiligen Anbietern. Für die tatsächliche Verbreitung fehlen datierte Serverantworten und Clientversionen. Die Dokumente belegen jedoch den Machtwechsel im Kleinen: Wer den Fehler benennt, schuldet den Nutzern dieses Namens Kontinuität.