HTTP-Wiederholungen mit einer Frist begrenzen und unbekannte Ergebnisse behandeln

Budgetieren Sie die gesamte Operation

Ein pro-Versuch-Zeitlimit begrenzt eine einzelne Anfrage. Eine Gesamt-Frist begrenzt die Operation über Versuche und Wartezeiten hinweg. Das Starten eines frischen zehnsekündigen Zeitlimits für jeden Wiederholungsversuch kann eine beabsichtigte zehnsekündige Operation in eine viel längere verwandeln.

Wählen Sie eine Uhr und einen Abbruchmechanismus, der zur Laufzeitumgebung passt, und prüfen Sie die Frist erneut, nachdem die Ausführung fortgesetzt wurde. Eine Uhrprüfung zwischen Versuchen bricht selbst keine laufende Anfrage ab. Eine vollständige Implementierung benötigt sowohl Planungsprüfungen als auch die Abbrüche von Arbeit, die die Operation überlebt.

Verstehen Sie den Zeitlimit-Mechanismus

In Browsern misst AbortSignal.timeout aktive Zeit. Diese Zeit kann pausieren, während ein Worker angehalten ist oder ein Dokument im Rückwärts-Cache ist. Beschreiben Sie sie nicht als universelle Wanduhr-Frist.

Wenn fetch ein Abbruchsignal erhält, kann es unterbrochen werden, wenn dieses Signal abbricht. Das Kombinieren von Signalen entfernt nicht die Notwendigkeit, eine Gesamt-Abbruchrichtlinie zu definieren. Diese Anleitung erklärt die Richtlinie statt eine vollständige Wiederholungsbibliothek bereitzustellen; Timer, Antwortkörper-Verarbeitung und Bereinigung müssen von der tatsächlichen Implementierung behandelt werden.

Entscheiden Sie, welche Anfragen wiederholt werden dürfen

HTTP-Idempotenz beschreibt die beabsichtigte Wirkung der Wiederholung einer identischen Anfrage. Sichere Methoden wie GET sind idempotent, und PUT sowie DELETE sind ebenfalls nach ihrer definierten Semantik idempotent. Das bedeutet nicht, dass jede Wiederholung denselben Status zurückgibt oder dass eine bestimmte Serverimplementierung korrekt ist.

Wiederholen Sie nicht automatisch jede erfolglose Antwort. Ein permanenter Validierungsfehler sollte nicht in dieselbe Richtlinie wie ein vorübergehender Dienstausfall eingehen. POST und PATCH sind nicht garantiert idempotent, daher benötigt ein unbekanntes Ergebnis den spezifischen Wiederherstellungs- oder Deduplizierungsvertrag der API.

Interpretieren Sie Retry-After vor der Planung

Retry-After kann eine nichtnegative Anzahl von Sekunden oder ein HTTP-Datum enthalten. Eine Verzögerung in Sekunden wird gemessen, nachdem die Antwort empfangen wurde. HTTP-Daten erfordern einen Vergleich mit der aktuellen Zeit und können von Uhrenunterschieden beeinflusst werden. Ein fehlender oder fehlerhafter Wert autorisiert kein unbegrenztes oder sofortiges Wiederholen.

Das Folgende ist ein beispielhaftes Antwortheader-Fragment, keine beobachtete Antwort oder eine vollständige Serverkonfiguration. Es bittet den Client, 120 Sekunden zu warten. Wenn diese Verzögerung nicht in das verbleibende Operationsbudget passt, stoppen Sie stattdessen, verkürzen Sie die angeforderte Verzögerung nicht und wiederholen Sie früher.

HTTP/1.1 503 Service Unavailable
Retry-After: 120

Verfolgen Sie einen konsistenten Zeitstrahl

Nehmen Sie an, eine hypothetische Operation beginnt bei Zeit null mit einer zehnsekündigen Frist. Versuch 1 schlägt fehl, und der gewählte Backoff erlaubt es, Versuch 2 bei Zeit drei Sekunden zu starten. Nehmen Sie für dieses Beispiel an, dass seine 503-Antwort zur selben Zeit mit Retry-After: 120 empfangen wird.

Es verbleiben sieben Sekunden, aber die angeforderte Wartezeit beträgt 120 Sekunden. Die erwartete Entscheidung ist, mit einem Grund wie retry_after_exceeds_deadline zu stoppen. Es gibt keinen dritten Versuch. Dies sind konstruierte Werte, um die Entscheidung zu erklären, keine Messungen aus einem Netzwerktest.

Wenn dieselbe hypothetische Antwort stattdessen drei Sekunden anfordert, würde das Warten bis Zeit sechs vier Sekunden übrig lassen. Ein weiterer Versuch ist nur möglich, wenn die Richtlinie es erlaubt und seine Arbeit durch diese verbleibenden vier Sekunden begrenzt ist; die Zeitplanung verspricht nicht, dass die Anfrage erfolgreich sein wird.

Begrenzen Sie Backoff und Versuchszahl

Wenn die API ein Wiederholen erlaubt und keinen brauchbaren Retry-After-Wert liefert, kann eine begrenzte Backoff-Richtlinie Versuche über die Zeit verteilen. Jitter variiert Wartezeiten, um zu vermeiden, dass synchronisierte Clients wiederholt gemeinsam ankommen. Definieren Sie die Obergrenze, die Zufallsgenerierung und die maximale Versuchszahl als Anwendungsrichtlinie, statt zu behaupten, das HTTP-Standardwerk würde einen universellen Algorithmus bereitstellen.

Prüfen Sie vor dem Schlafen, ob die gewählte Wartezeit genug Zeit für einen nützlichen nächsten Versuch lässt. Stoppen Sie, wenn dies nicht der Fall ist. Ein großer Retry-After-Wert ist ein Grund, eine kurze Operation aufzugeben, nicht ein Grund, die angeforderte Wartezeit des Servers zu begrenzen und vor Ablauf zu wiederholen.

Stellen Sie ein unbekanntes Schreibergebnis wieder her

Wenn eine Verbindung verschwindet, nachdem eine Schreibanfrage möglicherweise gesendet wurde, hat der Server sie möglicherweise committed, obwohl der Client keine Antwort erhielt. Das Wiederholen eines nebenwirkungshaltigen POST kann eine zweite Bestellung oder Gebühr erstellen. Halten Sie die Unterscheidung zwischen bestätigtem Erfolg, bestätigtem Fehlschlag und unbekanntem Ergebnis.

Ein dokumentierter Status-Endpunkt oder ein Idempotenzschlüssel-Vertrag kann helfen, das Ergebnis wiederherzustellen. Verwenden Sie einen Schlüssel nur gemäß diesem Vertrag, einschließlich seiner Nutzlast und Aufbewahrungsregeln. Das Senden eines beliebigen Headers macht keinen Server zu einem deduplizierenden Server, und eine Statusabfrage ist selbst keine Erlaubnis, einen zweiten Schreibvorgang auszuführen.

Protokollieren Sie den Grund für jede Entscheidung

Nützliche Diagnosen umfassen die Methode, die Versuchszahl, das verbleibende Budget, den Antwortstatus, die geparste Wartezeit und den Stoppgrund. Halten Sie Anmeldeinformationen, Autorisierungsheader und sensible Anfragekörper aus diesen Aufzeichnungen heraus.

Unterscheiden Sie einen Richtlinienstopp von einem Transportfehler, damit Betreiber wissen, ob das Budget erschöpft war, der Server um eine längere Wartezeit bat oder ein Schreibvorgang wiederhergestellt werden muss. Prüfen Sie dann repräsentative Fälle gegen die API-Dokumentation. Der beispielhafte Zeitstrahl stellt Arithmetik her, nicht die Zuverlässigkeit oder Leistung eines eingesetzten Clients.