it-swarm.com.de

REST Behandlung des API-Fehlercodes 500

Wir bauen eine neue REST - API.

Ich argumentierte, dass der Fehlercode 500 (Interner Serverfehler) niemals zurückgegeben werden sollte.

Wenn Sie nun wissen, dass die Parameter des Clients falsch sind, haben Sie alles unter Kontrolle und können einen entsprechenden Fehlercode (z. B. 422) zurückgeben.

Wenn also ein unerwarteter Fehler auftritt, könnte der Server

  1. NICHT unerwartete Fehler abfangen, so dass 500 Blasen zum Client gelangen
  2. Erfassen Sie alle unerwarteten Fehler und geben Sie einen Fehlercode zurück, der auf eine "unerwartete Situation" hinweist (ehrlich gesagt, ich konnte keinen solchen Fehlercode finden!)

Gibt es noch andere Möglichkeiten?

11
faboolous

Es ist ein Serverfehler, kein Clientfehler. Wenn Serverfehler nicht an den Client zurückgegeben werden sollen, wäre für sie keine gesamte Statuscode-Klasse erstellt worden (d. H. 5xx).

Sie können nicht die Tatsache ausblenden, dass Sie entweder einen Programmierfehler gemacht haben oder ein Dienst, auf den Sie sich verlassen, nicht verfügbar ist. Dies ist sicherlich nicht die Schuld des Kunden. Die Rückgabe eines anderen Codebereichs in solchen Fällen als die Serie 5xx wäre nicht sinnvoll.

RFC 7231 erwähnt in Abschnitt 6.6. Serverfehler 5xx :

Die Statuscode-Klasse 5xx (Server Error) gibt an, dass der Server ist sich dessen bewusst, dass es fehlerhaft ist oder das .__ nicht ausführen kann. angeforderte Methode.

Das ist genau der Fall. Es gibt nichts "Internes" über den Code "500 Internal Server Error" in dem Sinne, dass er dem Client nicht ausgesetzt werden sollte. 

13
CodeCaster

Die eigentliche Frage ist, warum es einen Fehler 500 erzeugt. Wenn es sich auf Eingabeparameter bezieht, würde ich argumentieren, dass es intern behandelt und als Fehler der Serie 400 zurückgegeben werden sollte. Im Allgemeinen wäre ein 400, 404 oder 406 geeignet, schlechte Eingaben widerzuspiegeln, da die übliche Konvention lautet, dass eine RESTful-Ressource eindeutig durch die URL identifiziert wird und eine URL, die keine gültige Antwort generieren kann, eine ungültige Anforderung (400) oder eine ähnliche ist.

Wenn der Fehler durch andere als die von der Anforderung explizit oder implizit gelieferten Eingaben verursacht wird, würde ich sagen, dass ein Fehler von 500 wahrscheinlich angemessen ist. Eine fehlerhafte Datenbankverbindung oder ein anderer unvorhersehbarer Fehler wird also durch einen Fehler der Serie 500 genau dargestellt.

5
tokkov

Sie haben vorgeschlagen "Unerwartete Fehler abfangen und einen Fehlercode zurückgeben, der" unerwartete Situation "signalisiert" ", aber es wurde kein entsprechender Fehlercode gefunden. 

Weißt du was: Dafür ist 5xx da. 

3
gnasher729

Im Allgemeinen weisen 5xx-Antwortcodes auf nicht programmatische Fehler hin, z. B. einen Datenbankverbindungsfehler oder einen anderen Ausfall der System-/Bibliotheksabhängigkeit. In vielen Fällen wird erwartet, dass der Client die gleiche Anforderung in der Zukunft erneut einreichen und erwarten kann, dass er erfolgreich ist.

Ja, einige Web-Frameworks antworten mit 5xx-Codes. Diese sind jedoch in der Regel auf Fehler im Code zurückzuführen, und das Framework ist zu abstrakt, um zu wissen, was passiert ist. Daher wird standardmäßig diese Art von Antwort verwendet. Dieses Beispiel bedeutet jedoch nicht, dass wir uns daran gewöhnen sollten, 5xx-Codes als Ergebnis eines programmatischen Verhaltens zurückzugeben, das nicht mit Out-of-Process-Systemen zusammenhängt. Es gibt viele gut definierte Antwortcodes, die besser geeignet sind als die 5xx-Codes. Wenn Sie eine bestimmte Eingabe nicht analysieren/validieren können, handelt es sich nicht um eine 5xx-Antwort, da der Code eine geeignetere Antwort enthalten kann, bei der der Client nicht der Meinung ist, dass er dieselbe Anforderung erneut absenden kann, obwohl er dies nicht kann.

Wenn der vom Server festgestellte Fehler auf eine CLIENT-Eingabe zurückzuführen ist, handelt es sich eindeutig um einen CLIENT-Fehler, der mit einem 4xx-Antwortcode behandelt werden sollte. Die Erwartung ist, dass der Client den Fehler in seiner Anfrage korrigiert und erneut sendet.

Es ist jedoch völlig akzeptabel, Fehler aus dem Prozess herauszufinden und als 5xx-Antwort zu interpretieren. Beachten Sie jedoch, dass Sie weitere Informationen in die Antwort aufnehmen sollten, um genau anzugeben, was fehlgeschlagen ist. und noch besser, wenn Sie SLA mal zur Adresse hinzufügen können.

Ich denke nicht, dass es eine gute Praxis ist, "einen unerwarteten Fehler" als 5xx-Fehler zu interpretieren, da Fehler auftreten.

Es ist ein allgemeiner Warnungsmonitor, um bei 5xx-Fehlertypen zu warnen, da diese normalerweise auf ausgefallene Systeme und nicht auf fehlerhaften Code hinweisen. Also entsprechend kodieren!

2
ILoveCode

In 80% der Fälle würde dies auf eine falsche Eingabe in der Datei soapRequest.xml zurückzuführen sein

0
harveySp