it-swarm.com.de

Sollten Sie 500 API-Fehler erneut versuchen?

Mein Team und ich integrieren uns in ein Drittunternehmen und verwenden deren API, um verschiedene CRUD-Operationen durchzuführen. Ihre API ist jedoch nicht immer zuverlässig. Möglicherweise schlägt ein API-Aufruf in 0,1% der Fälle nur mit einem Fehler von 500 fehl, und wenn Sie es erneut versuchen, funktioniert er einwandfrei. Gelegentlich kommt es vor, dass der API-Aufruf in mehr als 90% der Fälle mit einem 500-Fehler fehlschlägt. Nach ~ 10 Versuchen wird es endlich funktionieren. Es dauert normalerweise ungefähr 4 Stunden und tritt alle paar Monate auf. Wir haben dies gestern erlebt, als der API-Aufruf in 90% der Fälle fehlschlug.

Der Dritte sagte uns, dass wir eine Wiederholungslogik implementieren sollten, wenn ein 500-Fehler empfangen wird. Für idempotente Operationen konnte ich sehen, dass dies nützlich ist. Für nicht idempotente Operationen scheint es jedoch gefährlich zu sein. Ein API-Aufruf könnte beispielsweise darin bestehen, eine E-Mail zu senden. Wir haben manchmal festgestellt, dass die API möglicherweise einen 500-Fehler zurückgibt, obwohl die E-Mail gesendet wurde. Wenn ich den API-Aufruf 10 Mal erneut versuche, werden möglicherweise 10 500 Fehler angezeigt, aber der Empfänger erhält möglicherweise immer noch 10 E-Mails. Das könnte sehr schlimm sein.

Sollten wir tatsächlich Wiederholungslogik für 500 Fehler hinzufügen, die nicht idempotent sind?

Meine zwei Gedanken darüber, wann wir es erneut versuchen sollten:

  1. Wenn wir damit einverstanden sind, dass die Operation mehr als einmal ausgeführt wird
  2. Wenn der fehlgeschlagene Vorgang schlechter ist als der zehnmal erfolgreiche Vorgang (oder was auch immer das Wiederholungslimit ist).

Ich musste API-Aufrufen nie eine Wiederholungslogik hinzufügen, da das Erhalten von 500 Fehlern sehr gering ist. Ist es vernünftig, dies tun zu müssen?

5
Eric

Dies läuft darauf hinaus, was für die spezifische nicht-idempotente Operation schlimmer ist:

  • wenn es mehr als einmal ausgeführt wird, oder

  • wenn es überhaupt nicht ausgeführt wird.

Dies ist keine technische Entwurfsentscheidung, sondern hängt von der spezifischen Operation und den Folgen solcher Fehler in der Domäne ab.

Als technische Maßnahme können Sie prüfen, ob es zusätzliche Optionen zur Überprüfung gibt, ob eine bestimmte Operation stattgefunden hat (zumindest mit einer bestimmten Wahrscheinlichkeit). Nehmen wir das E-Mail-Beispiel: Wenn Sie mit der API E-Mail-Anfragen mit einer enthaltenen Blindkopie-Anfrage senden können, können Sie diese Funktion verwenden, um Ihrem eigenen System eine solche Blindkopie zu senden. Dies gibt Ihnen die Möglichkeit, einen zusätzlichen Prüfpunkt zu implementieren, ob die ursprüngliche E-Mail gesendet wurde oder nicht. Natürlich erreicht die Blindkopie aufgrund einer Netzwerkverzögerung möglicherweise nicht rechtzeitig Ihr System, aber Sie können die Häufigkeit doppelter E-Mail-Vorgänge über die API verringern.

Oder die API selbst ermöglicht es Ihnen, einen bestimmten Status oder Protokollierungsinformationen für bestimmte Vorgänge zu überprüfen. Obwohl diese Anrufe ebenfalls fehlschlagen können, können Sie die Fehlerrate möglicherweise mithilfe dieser Funktionen auf ein akzeptables Maß senken.

Als allgemeines Konstruktionsprinzip: Wenn Sie eine unzuverlässige Komponente in Ihrem System haben, erstellen Sie genügend Redundanz, um das System "zuverlässig genug" zu machen.

7
Doc Brown

Stellen Sie fest, ob Ihr API-Aufruf "mindestens einmal", "höchstens einmal" oder "genau einmal" lautet ( http://www.cs.unc.edu/~dewan/242/f97) /notes/ipc/node27.html ) in Bezug auf die Dringlichkeit. Schreiben Sie mindestens einmal eine Wiederholungslogik mit einer Art Backoff (z. B. exponentiellem Backoff). Implementieren Sie in anderen Fällen eine bessere Überwachung und Alarmierung, damit Sie wissen, wenn etwas schief geht. Verschieben Sie fehlgeschlagene Vorgänge in eine Warteschlange und implementieren Sie eine Benutzeroberfläche, mit der Sie Vorgänge manuell aus der Warteschlange auswählen und ausführen können.

6
sul4bh

Als Faustregel ja. 5xx sind "Serverfehler" und in der Welt der REST APIs) tritt dies häufig auf. NICHT so häufig wie in Ihrem Fall, aber häufig.

Z.B. Für unsere APIs, die in AWS mithilfe von API-Gateways und Java Lambda werfen durchschnittlich alle 2 Tage 500/503/504) gehostet werden. In der Regel wird der erste Wiederholungsversuch durchgeführt. Probleme sind vorübergehende Infrastrukturprobleme, Gateway Konnektivität, Lamba nicht erreichbar, Netzwerkprobleme ...

ALL REST Aufrufe sollten mit exponentiell zunehmender Verzögerung zwischen Wiederholungsversuchen für 5xx-Fehler wiederholt werden. In allen Bibliotheken sind Bibliotheken verfügbar, die nicht für Schleifen verwendet werden.

Idempotenz macht die Sache natürlich etwas komplizierter, aber ich würde mich an die Faustregel halten. Z.B. 503, 504 bedeutet sicherlich, dass Sie es erneut versuchen können. Die API muss einige Garantien geben oder Hinweise zum Verhalten für 500s geben.

Natürlich stimme ich der Meinung anderer zu, dass keine bezahlte API 4 Stunden lang nicht verfügbar sein sollte .

2
Kashyap

In der Regel sollten 500 Fehler wiederholt werden. Für die meisten Fehlercodes gilt eine Faustregel:

  • 2xx = Alles was getan werden kann wurde getan.
  • 4xx = Sie (der Anrufer) haben etwas falsch gemacht oder nach etwas Unsinnigem gefragt.
  • 5xx = Wir (der Server) haben etwas falsch gemacht.

4xx-Fehler führen im Allgemeinen zu einer Anforderung, die von Natur aus fehlerhaft ist und nicht behandelt werden kann. 5xx-Fehler werden verwendet, um anzuzeigen, dass auf dem Server ein privates Problem aufgetreten ist, und es gibt keinen Hinweis darauf, dass Ihre Anfrage nachweislich ungültig ist.

Das bedeutet nicht, dass Ihre Anfrage gültig gewesen sein muss. Angenommen, Sie senden eine Anforderung zum Abrufen eines Elements, verwenden jedoch eine nicht vorhandene ID. Ein Server, der die Anfrage gut verarbeitet, gibt Ihnen eine 404-Antwort (oder eine 204. Ich habe so oder so Argumente gehört und denke, die Unterscheidung ist kontextabhängig). Wenn der Server jedoch einen Fehler aufweist, der zu einer Nullreferenzausnahme führt, erhalten Sie wahrscheinlich eine Antwort von 500.

Wenn Sie als Anrufer eine Antwort von 500 erhalten, wissen Sie nicht, was schief gelaufen ist. Sie wissen nur, dass der Server Ihnen nicht aktiv mitgeteilt hat, dass Ihre Anfrage unsinnig ist. Dies bedeutet, dass Sie nicht davon ausgehen können, dass es keinen Sinn macht, dieselbe Anfrage erneut zu stellen.
Vielleicht haben Sie die 500 erhalten, weil die Serverdatenbank offline war. Wenn Sie etwas warten und es erneut versuchen, ist dies möglicherweise erfolgreich, da die Datenbank online ist.

Wenn Sie jedoch einen 4xx-Fehler erhalten, hat der Server aktiv angegeben, dass Ihre Anfrage nicht auflösbar ist und es keinen Sinn macht, es erneut zu versuchen.

Dies ist eine Art Übergeneralisierung, es gibt Randausnahmen. Zum Beispiel bedeutet Status 429 (zu viele Anfragen), dass Sie (der Anrufer) Ihre zugewiesene Anzahl von Anrufen überschritten haben, aber es ist wahrscheinlich, dass dieselbe Anfrage korrekt verarbeitet wird, wenn Sie warten, bis Ihnen weitere Anfragen zugewiesen wurden (z. B. wenn Wenn Sie das Tagesmaximum erreicht haben, wird es morgen wieder funktionieren.


Sul4bh ist jedoch richtig, dass dies kontextabhängig sein kann und dass einige Anwendungen möglicherweise nicht möchten, dass Sie dieselbe Anforderung mehrmals senden.

Betrachten Sie beispielsweise eine Banküberweisung. Sie senden die Anfrage und erhalten eine 500. In Wirklichkeit hat der Server Ihre Anfrage tatsächlich verarbeitet, aber bei der Formatierung der Antwortnachricht ist ein geringfügiger Fehler aufgetreten.
Das erneute Senden Ihrer Anfrage kann schädlich sein, da Sie am Ende mehrere Bankgeschäfte tätigen.

Ich glaube jedoch nicht, dass es an Ihnen (dem Anrufer) liegt, zu entscheiden, wann Sie dieselbe Anfrage auslösen dürfen und wann nicht. Es liegt in der Verantwortung des Servers, dem Anrufer den tatsächlichen Status der Dinge klar mitzuteilen, und im obigen Szenario ist dies nicht gelungen. Sie können nicht dafür verantwortlich gemacht werden, dass Sie schlechte Informationen erhalten und korrekt auf die angegebenen Informationen reagieren.

Wenn ich eine Zahlung per Online-Banking tätige und bei Übermittlung der Transaktion eine 500 erhalte, werde ich es erneut versuchen. Es ist die sinnlichste Antwort auf einen 500-Fehler. Zu diesem Zweck hat meine Bank tatsächlich einen Scheck eingeführt. Wenn festgestellt wird, dass Sie schnell hintereinander eine zweite Überweisung für denselben Betrag und/oder auf dasselbe Konto vornehmen, wird Ihnen mitgeteilt, dass die erste Transaktion tatsächlich registriert wurde.

Das hängt also sehr vom Server ab. Von ihnen wird erwartet, dass sie klar mit Ihnen kommunizieren. Wenn Sie von einer klaren Kommunikation ausgehen, bedeutet ein 500, dass Sie es zu einem späteren Zeitpunkt erneut versuchen sollten, da die Ursache des Problems auf dem Server lag und nicht in Ihrer Anfrage.
Wenn der Server nicht klar kommunizieren kann oder der Kontext der Anwendung erfordert, dass der Anrufer auf der Seite irrt, niemals zweimal dieselbe Aktion auszuführen, müssen und sollten die Administratoren des Servers dies den Verbrauchern ihrer API klar mitteilen Ergreifen Sie angemessene Anstrengungen, um zu verhindern, dass fälschlicherweise zweimal dieselbe Maßnahme ergriffen wird.

1
Flater