Zusammenfassung

  • RFC 9110 nennt das Methodentoken die wichtigste Quelle der Anfragesemantik: Es beschreibt Zweck und erwarteten Erfolg des Clients; jede Zielressource entscheidet trotzdem selbst über Erkennung, Implementierung und Zulassung.
  • Safe begrenzt die angeforderte Bedeutung, nicht sämtliche Nebenwirkungen. Idempotent begrenzt die beabsichtigte Wirkung identischer Wiederholungen, nicht Antwort, Protokoll oder Außenwirkung.
  • Ein belastbarer Vorgangsnachweis verbindet Methode, Ziel, authentifizierten Principal, Autorisierung, Vorbedingung, Unsicherheit des ersten Versuchs, Anwendungsidempotenz, Wiederholungsakteur, Antwort, Endzustand und Folgewirkungen.

PUT sieht wie eine Anweisung aus. Im Protokoll ist es eine öffentlich verständliche Absicht. Diese Sichtbarkeit lässt unabhängige Software begrenzt schlussfolgern: Ein Cache erkennt eine Änderung, ein Gateway kann Regeln anwenden, ein Client kann nach einem Verbindungsabbruch über Wiederholung nachdenken.

Das Wort entscheidet aber nicht, ob der Server PUT kennt, ob genau diese Ressource es unterstützt, ob der angemeldete Principal schreiben darf, ob der vorausgesetzte Zustand noch gilt oder ob der erste Versuch bereits committed wurde. Wer diese Fragen in das Verb hineinliest, verliert die Ursache einer Ablehnung ebenso wie den Beleg eines Erfolgs.

Gemeinsame Semantik endet vor der lokalen Zulassung

Nach RFC 9110 zeigt die Methode, weshalb der Client eine Anfrage gestellt hat und welches Ergebnis er als erfolgreich erwartet. GET fordert eine aktuelle Repräsentation an. PUT fordert, den dargestellten Zustand an einem gewählten Ziel zu erzeugen oder zu ersetzen. DELETE fordert, die Zuordnung zwischen Ziel-URI und gegenwärtiger Funktion zu entfernen; physische Vernichtung aller Daten ist nicht zugesagt.

Standardisierte Methoden sollen bei jeder Ressource dasselbe bedeuten. Dadurch können allgemeine Komponenten Verhalten sehen und wiederverwenden, ohne die Anwendung zu öffnen. Doch jede Ressource bestimmt, ob sie die Semantik implementiert und zulässt. Unbekannt oder nicht implementiert führt zu 501. Bekannt und implementiert, aber für das Ziel nicht unterstützt, führt zu 405 mit einem aktuellen Allow.

Allow ist keine Berechtigungsliste. Ein Dokument kann PUT unterstützen und es nur Redakteuren erlauben. Authentifizierung klärt die Identität, Autorisierung wendet eine Richtlinie auf Identität, Aktion und Ziel an, Methodenunterstützung beschreibt die Fähigkeit der Ressource. Diese Nachweise dürfen nicht zusammenfallen.

Heng Lus Minimum Initial Specification liefert dafür die institutionelle Lesart: Die gemeinsame Schicht enthält nur die strikte Semantik, die Interoperabilität erfordert. Geschäftsregeln bleiben bei den Betreibern. Das IANA-Register ist ein Vokabular-Ledger, kein globaler Policy-Entscheider.

Safe verteilt Verantwortung, beseitigt aber keine Wirkung

Eine sichere Methode ist in ihrer definierten Semantik im Wesentlichen lesend. Der Client fordert keine Zustandsänderung beim Origin an. RFC 9110 grenzt dies sofort ein: Ein Server kann Zugriffsprotokolle schreiben, ein Werbeklick kann ein Konto belasten, eine Implementierung kann weitere Effekte auslösen. Der Client hat diese Zusatzhandlungen nicht verlangt und trägt dafür nicht automatisch Verantwortung.

Diese Grenze ermöglicht Linkprüfung, Indexierung und Vorladen. Der Ressourceninhaber muss unsichere Aktionen unter sicheren Methoden verhindern. Ein GET auf page?do=delete darf nicht löschen. Ein gefährlicher Parameter verwandelt den Crawler nicht in einen Akteur mit Löschabsicht.

Die Prüfung braucht deshalb zwei Spalten: die vom Client verlangte Zustandsänderung und die vom Server hinzugefügten Effekte. Logs, Abrechnung, Quotenverbrauch, Tracking und externe Benachrichtigungen gehören in die zweite. Safe bedeutet außerdem nicht frei zugänglich. Ein vertrauliches Dokument bleibt auch bei GET autorisierungspflichtig.

Idempotent bedeutet Konvergenz der beabsichtigten Wirkung

Mehrere identische Anfragen sind idempotent, wenn ihre beabsichtigte Serverwirkung der einer einzelnen Anfrage entspricht. RFC 9110 zählt PUT, DELETE und sichere Methoden dazu. Jede Ausführung kann dennoch einen eigenen Logeintrag, eine neue Revision oder eine andere Antwort erzeugen.

Nach einem erfolgreichen DELETE kann die Wiederholung die Ressource bereits abwesend finden. Nach wiederholtem PUT kann derselbe Zielzustand einen anderen Zeitstempel oder ETag tragen. Stabil ist die verlangte Wirkung, nicht die gesamte Umgebung.

Anwendungslogik kann das sichtbare Versprechen brechen. Ein PUT, der einen Betrag addiert, vervielfacht das Ergebnis. Ein DELETE, das bei jedem Versuch einen neuen irreversiblen Auftrag an ein Fremdsystem sendet, konvergiert lokal und divergiert extern.

Deshalb braucht jede irreversible Grenze einen stabilen operation key, Commit-Status, Deduplizierung und gegebenenfalls Kompensation. Protokollidempotenz ist keine verteilte Transaktion.

Wiederholung beginnt mit Unwissen über den ersten Versuch

Bricht die Verbindung vor der Antwort ab, kann die Anfrage vor dem Server verloren, bereits angewandt oder nur ohne Antwort geblieben sein. Eine idempotente Anfrage lässt sich vernünftig wiederholen, weil der zweite Versuch auch nach einem erfolgreichen ersten zum gleichen beabsichtigten Effekt führen sollte.

RFC 9110 erlaubt keine Endlosschleife. Nicht-idempotente Methoden sollen nur dann automatisch wiederholt werden, wenn die konkrete Ressource die Operation tatsächlich konvergent macht oder der Client erkennen kann, dass der erste Versuch nie angewandt wurde. Ein Proxy darf solche Anfragen nicht automatisch wiederholen. Nach einer fehlgeschlagenen automatischen Wiederholung soll keine weitere automatische Kette folgen.

Der Wiederholungsnachweis braucht Abbruchpunkt, Ziel, Inhaltshash, Vorbedingung, Anwendungsschlüssel, abfragbaren Operationsstatus, Versuchszahl und Backoff. POST kann mit stabilem Schlüssel wiederherstellbar sein. PUT kann mit ungebremsten Außenwirkungen gefährlich sein.

Running-Code Primacy richtet den Blick auf überprüfbares Verhalten: Konvergieren Duplikate wirklich? Ist der Commit abfragbar? Bleiben Folgen begrenzt? Das Registeretikett ist erst dann belastbar, wenn der Betrieb es bestätigt.

If-Match schützt eine Version, nicht den Principal

If-Match verlangt, dass der aktuelle ETag noch dem bekannten Wert entspricht, bevor die Änderung angewandt wird. Ist die Bedingung falsch, wird die Methode nicht ausgeführt; typischerweise folgt 412. So überschreibt eine alte Kopie keine neuere Bearbeitung.

Die Kenntnis eines ETag gewährt kein Schreibrecht. Ein Schreibrecht aktualisiert keinen veralteten ETag. Autorisierung beantwortet, ob dieser Principal handeln darf; die Vorbedingung beantwortet, ob der angenommene Zustand noch besteht. Beide Ablehnungen brauchen einen eigenen Grund.

Nach einer verlorenen Antwort kann der aktuelle Zustand erkennen lassen, dass der erste Versuch schon angewandt wurde. Bei unkoordinierten Autoren mit ähnlichen Änderungen ist diese Folgerung jedoch riskant. Das Ressourcenmodell bestimmt die Wiederherstellbarkeit mit.

QUERY macht eine bisher private Eigenschaft öffentlich

RFC 10008 wurde im Juni 2026 von Julian Reschke, James Snell und Mike Bishop veröffentlicht, nicht von Fielding. QUERY trägt Inhalt wie POST, deklariert jedoch eine sichere und idempotente Abfrage. IANA führt beide Eigenschaften mit yes.

Komplexe Abfragen in einer URI können zu lang sein oder in Logs und Verläufen erscheinen. Anwendungen nutzen deshalb häufig POST zum Lesen. Für eine allgemeine Komponente bleibt unsichtbar, dass gerade dieser POST sicher und wiederholbar ist. QUERY veröffentlicht die Absicht, während die Ressource Inhalt und Unterstützung weiter selbst bestimmt.

Registrierung ist keine Einführung. Gateways können die Methode nicht weiterleiten, Server 501, Ressourcen 405 und die Policy eine Autorisierungsablehnung liefern. Das Register ist eine Semantiktabelle, keine ACL.

Fieldings Beitrag ist eine Schnittstellengrenze

Der am 31. August 2026 geprüfte IETF Datatracker beschreibt Roy T. Fielding als Senior Principal Scientist bei Adobe, Mitgründer der The Apache Software Foundation, Autor von REST und Mitwirkenden an HTTP, URI und URI Templates. Er listet 18 RFCs und eine Reviewer-Rolle im HTTP Directorate. UC Irvine dokumentiert Abschlüsse und Beiträge zu Web, REST und Apache.

Seine Dissertation beschreibt die einheitliche Schnittstelle als REST-Beschränkung, die Sichtbarkeit, Wiederverwendung, Skalierbarkeit und unabhängige Entwicklung verbessert, aber anwendungsspezifische Effizienz kostet. Methoden zeigen diesen Tausch: gemeinsame Absicht wird sichtbar, Speicherung, Policy und Ausführung bleiben verborgen und lokal.

RFC 9110 hat drei Herausgeber: Fielding, Mark Nottingham und Julian Reschke. HTTP ist kollektive, fortgeschriebene Arbeit. RFC 10008 gehört ihren genannten Autoren. Eine Signatur macht einen Beitrag nachweisbar; sie begründet kein Eigentum am Protokoll.

Der Vorgangsnachweis beginnt hinter dem Verb

Erfasst werden Methode, Ziel-URI und Origin, authentifizierter Principal und Credential-Scope, Ressourcenunterstützung, Autorisierungsentscheidung samt Richtlinienversion, ETag, Inhaltshash und beabsichtigte Wirkung. Nach einer Störung kommen letzter bestätigter Übertragungspunkt, mögliche Anwendung des ersten Versuchs, operation key, Wiederholungsakteur, Anlass, Zahl und Backoff hinzu.

Abgeschlossen wird mit Antwort, erneut gelesenem Zustand, Folgewirkungen, Kompensation und Irreversibilität. Die Methode sagt, was der Client beabsichtigt. Die Ressource sagt, ob sie es versteht. Die Policy sagt, ob dieser Principal es darf. Die Vorbedingung sagt, ob der Zustand noch passt. Wiederholungsbelege sagen, ob ein weiterer Versuch vertretbar ist.

Eine Methode benennt eine Absicht. Sie verleiht keine Berechtigung.

Quellen