Zusammenfassung

  • Der inzwischen abgelaufene HTTPAPI-Entwurf zu Idempotency-Key ordnet Schlüssellebenszyklus und Ablaufpolitik dem Ressourcenvertrag zu. Aktuelle Stripe-Dokumentation und AWS-Beispiele zeigen unterschiedliche Aufbewahrungsgrenzen, keine allgemeine Frist.
  • Gedächtnis zur Duplikaterkennung und Befugnis zur erneuten Wirkung müssen getrennt werden. Eine alte Operation mit unbekanntem Ausgang wird außerhalb des Fensters abgeglichen oder angehalten. Ein fehlender Schlüssel beweist nicht, dass die erste Ausführung ausblieb.

Eine fehlende Antwort ist keine vollständige Geschichte. Der Server hat die Anfrage möglicherweise noch nicht angenommen, arbeitet weiter oder war schon fertig, als die Verbindung abriss. Der Client sieht denselben Timeout. Die richtige nächste Handlung hängt jedoch davon ab, welcher dieser Zustände tatsächlich vorliegt.

Idempotenzmechanismen sollen einen Teil dieser Unsicherheit beherrschbar machen. Ein Schlüssel lässt den Dienst einen späteren Versuch als Wiederholung erkennen. Innerhalb des zugesagten Vertrags kann er das frühere Ergebnis zurückgeben oder einen laufenden Vorgang anzeigen, statt eine weitere Wirkung zu erzeugen.

Doch ein angehaltener Worker kann Tage später mit derselben Nutzlast und demselben Schlüssel zurückkehren. Inzwischen hat der Server den zugehörigen Eintrag vielleicht nach seiner Aufbewahrungsregel gelöscht. Für die Erkennung sieht die alte Anweisung nun wie eine erste Anfrage aus. Neue Absicht ist dadurch nicht notwendigerweise entstanden. Nur das Gedächtnis einer Seite hat sich verändert.

Deshalb ist die Aussage „sichere Wiederholungen“ ohne Grenzen unvollständig. Sie hängt von Dienst, Operation, Identitätsscope, Parametervergleich und Dauer der gespeicherten Informationen ab. Ein zufälliger Wert kennzeichnet einen Versuch. Er beweist weder, dass vorher nichts geschah, noch erlaubt er nach dem Vergessen eine zweite Wirkung.

draft-ietf-httpapi-idempotency-key-header-07, veröffentlicht am 15. Oktober 2025, beschreibt einen solchen Vertragsentwurf. Er schlägt ein strukturiertes Headerfeld mit Zeichenkettenwert, Eindeutigkeit, einen optionalen Fingerabdruck der Nutzlast und unterschiedliche Behandlung abgeschlossener und gleichzeitiger Duplikate vor. Die Ressource verwaltet den Lebenszyklus und veröffentlicht eine anwendbare Ablaufpolitik.

Die Revision ist am 18. April 2026 abgelaufen. Datatracker führt sie zum Recherchezeitpunkt als archivierten HTTPAPI-Working-Group-Internet-Draft. Sie ist weder aktiver Entwurf noch RFC oder verabschiedeter Standard. Arbeitsgruppenherkunft bedeutet keine Konsensbestätigung. Die folgende Analyse verbindet vorgeschlagene Semantik mit tatsächlicher Dienstdokumentation, ohne daraus universelle HTTP-Pflichten zu machen.

Ein Timeout bestimmt keinen Endzustand

RFC 9110 beschreibt Methodenidempotenz anhand der beabsichtigten Wirkung wiederholter Aufrufe. Es geht nicht um identische Antworten oder Protokolleinträge und nicht um eine garantierte einmalige Ausführung über alle beteiligten Systeme. Ein Dienst kann einer POST- oder PATCH-Operation einen idempotenten Vertrag geben. Ein Header allein macht beliebige Änderungen aber nicht global genau einmal ausführbar.

Der Entwurf weist darauf hin, dass ein allgemeiner Client ohne Vorwissen nicht annehmen kann, ein beliebiger Server respektiere den Schlüssel. Der Ressourcenvertrag muss Eindeutigkeit, Vergleich, Dauer und Verhalten während einer laufenden Bearbeitung erklären. Das Wiederholen innerhalb dieser Regeln ist etwas anderes als das beliebige erneute Senden einer alten Absicht.

Ein abgeschlossener Versuch kann ein früheres Ergebnis einschließlich Fehler zurückliefern. Ein noch laufender Versuch kann einen Konflikt erzeugen. Derselbe Schlüssel mit anderer Nutzlast ist ein Identitätsproblem. Die vorgeschlagenen Reaktionen unterscheiden diese Fälle. Sie sind keine austauschbaren Anlässe, einfach einen neuen Schlüssel zu erfinden und erneut zu mutieren.

Auch ein Nutzlastfingerabdruck braucht Semantik. Der Vergleich aller oder ausgewählter Felder legt fest, welche Änderungen zählen. Ein inzwischen wichtiger, ausgelassener Parameter kann verschiedene Absichten gleich erscheinen lassen. Eine harmlose Formatnormalisierung kann dieselbe Absicht auseinanderreißen. Hohe Zufälligkeit des Schlüssels behebt diese Fehlzuordnung nicht.

Aufbewahrung gehört zum Sicherheitsversprechen

Alle Schlüssel, Antworten und Nutzlasten unbegrenzt zu speichern wäre teuer und häufig datenschutzrechtlich oder betrieblich unangemessen. Die Lebensdauer von Ressourcen, mögliche Verzögerungen und Kollisionsbereiche unterscheiden sich. Die Frage lautet nicht, ob gelöscht werden darf, sondern welche Garantie danach endet und welcher Abgleich noch möglich bleibt.

Stripe beschreibt in seiner aktuellen offiziellen Dokumentation ein konkretes Verhalten. Sobald die Ausführung eines Endpunkts beginnt, speichert es den ersten Statuscode und Antwortkörper des Schlüssels, einschließlich Fehlern. Scheitern Validierung oder ein gleichzeitiger Konflikt vor dem Beginn, wird dieses Ergebnis nicht gespeichert. Schlüssel dürfen entfernt werden, wenn sie mindestens 24 Stunden alt sind; Wiederverwendung nach Entfernung des ursprünglichen Eintrags erzeugt eine neue Anfrage.

Das ist keine Zusage eines exakten Ablaufs jeder einzelnen Taste nach 24 Stunden, keine allgemeine Anbieterregel und kein Bericht über eine doppelte Abbuchung. Es ist ein spezifischer Vertrag. Ein Client, dessen Warteschlange Tage später wieder anlaufen kann, darf den ursprünglichen Schlüssel nicht als zeitlich unbegrenzte Absicherung behandeln.

AWS schildert in Builders Library eine andere Situation. Eine verspätete Wiederholung kommt an, nachdem ein anderer Akteur die erzeugte Ressource gelöscht hat. Im EC2-Beispiel bleibt eine semantisch entsprechende Antwort erhalten, statt die Ressource neu anzulegen. Der Bericht beschreibt eine Aufbewahrung entlang der Ressourcenlebensdauer plus einem Intervall für späte Ankünfte und betont unterschiedliche Anforderungen je Dienst und Ressource.

Die Beispiele liefern keinen gemeinsamen TTL. Kurze SDK-Versuche, lange getrennte Geräte, Backups und manuelle Unterstützung haben unterschiedliche Wiederkehrhorizonte. Diese müssen mit der jeweiligen Wiedererkennungsfrist verglichen werden. Mehr Backoff verteilt Last, stellt aber gelöschtes Wissen nicht wieder her.

Vier Identitäten sind besser als eine

Der Duplikatschlüssel erkennt einen Versuch im vereinbarten Bereich. Die Geschäftsoperation bezeichnet die erlaubte Anweisung. Die Wirkung oder Ressource bezeichnet das tatsächlich Erzeugte. Eine neue Absicht kann eine zusätzliche Wirkung erlauben. Diese Identitäten sind verbunden, aber nicht gleich.

Ein neuer Schlüssel beweist keine neue Absicht. Ein alter Schlüssel nach Löschung beweist keinen früheren Fehlschlag. Eine gelöschte Ressource beweist nicht, dass sie nie existierte. Umgekehrt können identische Parameter zu einer berechtigten zweiten Entscheidung gehören. Befugnis lässt sich nicht allein aus gleichen oder verschiedenen Bytes ableiten.

Ein kompakter, länger haltbarer Operationsdatensatz kann diese Unterscheidung bewahren. Er kann Anfragendenbereich, erlaubte Anweisung, Parameterbindung, Annahmezeit, Endzustand, Wirkungsreferenz und Abgleichweg enthalten. Dafür müssen nicht alle sensiblen Nutzlasten und vollständigen Antworten für immer kopiert werden. Zweck, Zugriff und Aufbewahrung brauchen weiterhin Begrenzung.

Dieser Datensatz ist eine Governance-Empfehlung, kein neu erfundenes Pflichtfeld des IETF-Entwurfs. Dienste können den erforderlichen Ausgang verschieden verwirklichen. Die engere Bedingung lautet: Mit dem normalen Wiederholungsdatensatz darf nicht gleichzeitig die einzige Möglichkeit verschwinden, über eine alte unklare Anweisung zu entscheiden.

Das Verhalten nach Ablauf muss feststehen

Eine Ablaufpolitik sollte Startzeit, Identitätsscope, Operationstyp, gespeicherte Fehler und laufende Arbeit erklären. Sie sollte sagen, ob eine späte Anfrage zurückgewiesen, abgefragt, abgeglichen oder überprüfbar angehalten wird. Eine Speicherfrist allein ist noch kein Wiederherstellungsverfahren.

Außerhalb des Fensters darf eine alte unklare Wiederholung nicht stillschweigend zu neuer Ausführung werden. Der Client kann automatische Zustellung stoppen, bekannte Operation oder Ressource abfragen und Unsicherheit eskalieren. Ein zusätzlicher Effekt braucht eine ausdrücklich neue Absicht, die sich von der alten Wiederherstellung unterscheiden lässt.

Ein Dienst kann veröffentlichen, dass ein gelöschter Schlüssel bei Wiederverwendung neue Bearbeitung auslöst. Dann muss der Client diese technische Grenze beachten, statt weiterhin das frühere Versprechen zu behaupten. Sendbarkeit ist keine erneute geschäftliche Ermächtigung.

Auch der menschliche Knopf gehört in diesen Vertrag. Ein Supportmitarbeiter, der nach drei Tagen neu versucht, handelt möglicherweise außerhalb des SDK-Fensters von Sekunden. Ein neuer Schlüssel zur Konfliktumgehung kann ein Ticket schließen und zugleich eine zweite Operation eröffnen. Das sollte in Oberfläche und Arbeitsanweisung sichtbar werden.

Gedächtnis und Wirkung müssen zusammenpassen

Wird der Schlüssel gespeichert, ohne die Ressource zu erzeugen, droht falsche Fertigmeldung. Wird die Ressource erzeugt, ohne den Schlüssel zu speichern, droht Wiederholung. AWS betont die atomare Koordination zwischen Identitätsaufzeichnung und den zugehörigen Änderungen.

Eine lokale Transaktion umfasst allerdings nicht immer alle nachgelagerten Wirkungen. Das erste System kann seine Zeile bestätigen, ein zweites kann eine Anweisung ausführen und die Antwort verlieren. Der Endzustand muss auf die für jede Wirkung maßgebliche Quelle verweisen. Fertig im ersten Datenbestand heißt nicht fertig in der gesamten Kette.

Tests sollten Ankünfte nach Ablauf, Wiederholungen nach Ressourcenlöschung, geänderte Parameter, andere Anfragendenbereiche und teilweise Erledigung in einem weiteren Dienst enthalten. Erfolg ist nicht nur ein sauberer Statuscode. Es ist das Ausbleiben einer nicht autorisierten zweiten Wirkung und eine ehrliche Beschreibung des weiterhin unbekannten Zustands.

Ein Backup kann alte Anweisungen zurückbringen, ein Gerät spät wieder online gehen, ein Supportexport bereits abgeglichene Arbeit erneut zustellen. Das sind normale Wiederherstellungspfade. Wer sie als Randfall ausklammert, überlässt dem Speicherablauf eine Entscheidung über Handlungsmacht.

Quellen

  1. Datensatz des abgelaufenen Entwurfs
  2. Entwurfshistorie
  3. Revision 07 als HTML
  4. Revision 07 als Text
  5. XML der Revision 07
  6. HTTPAPI-Charta
  7. HTTPAPI-Dokumente
  8. Offizielles Quellrepository
  9. Offizielle Problemdiskussion
  10. RFC 9110: HTTP-Semantik
  11. RFC 9457: API-Problemdetails
  12. RFC 8941: Strukturierte HTTP-Felder
  13. RFC 9562: UUIDs
  14. RFC 9111: HTTP-Caching
  15. Stripe: Idempotente Anfragen
  16. Stripe: Fehlerbehandlung auf niedriger Ebene
  17. AWS: Sichere Wiederholungen mit idempotenten APIs
  18. AWS: Timeouts, Wiederholungen und Backoff
  19. Lu Heng: Minimale Anfangsspezifikation und lokale Entscheidung
  20. Lu Heng: Der Spiegel der Politik