2015-01-07 10 views
9

Wir erstellen eine neue REST-API.REST API Fehlercode 500 Handhabung

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

Nun, natürlich, wenn Sie wissen, dass die Parameter des Clients falsch oder etwas sind, haben Sie alles unter Kontrolle und können einen geeigneten Fehlercode (z. B. 422) zurückgeben.

Also, wenn ein unerwarteter Fehler auftritt der Server könnte:

  1. NICHT unerwartete Fehler fangen, so dass 500 Blasen bis zum Client
  2. Fang unerwartete Fehler und einige Fehlercodes zurück eine „unerwartete Situation“ Signalisierung (ehrlich gesagt konnte ich keinen solchen Fehlercode finden!)

Gibt es andere Optionen?

Antwort

9

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

Sie können nicht die Tatsache verbergen, dass Sie entweder einen Programmierfehler gemacht haben oder ein Dienst, auf den Sie sich verlassen, nicht verfügbar ist, und das ist sicherlich nicht der Fehler des Kunden. Die Rückgabe eines anderen Codebereichs in diesen Fällen als der 5xx-Serie wäre sinnlos.

RFC 7231 mentions in section 6.6. Server Error 5xx:

Die 5xx (Server Error) Klasse von Statuscode gibt an, dass der Server bewusst ist, dass es Fehler begangen hat oder nicht in der Lage die angeforderte Verfahren zur Durchführung.

Dies ist genau der Fall. Es gibt nichts "internes" über den Code "500 Internal Server Error" in dem Sinne, dass er dem Client nicht zur Verfügung gestellt werden sollte.

+0

verstanden und sind damit einverstanden. Ich habe versucht herauszufinden, ob ein Unterschied gemacht werden kann, wenn der Entwickler alle Fälle behandelt oder nicht. Eigentlich macht es keinen Sinn, so zu denken. Es gibt keinen Unterschied, wenn ein Entwickler einen unerwarteten Fehler entdeckt und 500 zurückgibt oder ihn nicht abfängt - der Test ist fehlgeschlagen, und das ist das wichtige Problem, denke ich. – faboolous

+1

Wenn Sie zwischen einer behandelten und einer nicht behandelten Serverausnahme unterscheiden möchten, können Sie das mit der Protokollierung (auf der Serverseite) oder im Anfragetext (also dem Client, in diesem Fall Ihrem Test) tun. – CodeCaster

+0

hilfreiche Klarstellung. Kann dieser 500-Statuscode jedoch aufgrund von Formatierungsproblemen im Anfragetext vom Server zurückgegeben werden? –

5

Die eigentliche Frage ist, warum es einen 500 Fehler erzeugt. Wenn es mit irgendwelchen Eingabeparametern zusammenhängt, dann würde ich argumentieren, dass es intern behandelt werden sollte und als 400-Serienfehler zurückgegeben werden sollte. Im Allgemeinen wäre eine 400, 404 oder 406 angemessen, um eine schlechte Eingabe widerzuspiegeln, da die allgemeine Konvention ist, dass eine REST-Ressource durch die URL eindeutig identifiziert wird und eine URL, die keine gültige Antwort generieren kann, eine ungültige Anforderung (400) oder Ähnliches ist.

Wenn der Fehler durch etwas anderes als die Eingaben verursacht wird, die explizit oder implizit von der Anfrage geliefert werden, würde ich sagen, dass ein Fehler von 500 wahrscheinlich angemessen ist. So wird eine fehlgeschlagene Datenbankverbindung oder ein anderer unvorhersehbarer Fehler genau durch einen Fehler der 500-Reihe dargestellt.

+1

_ "Wenn es mit ** irgendwelchen Eingabeparametern zusammenhängt ** [..]: 400" _ - was ist, wenn der Fehler durch eine nicht erfasste Null-Dereferenzierungsausnahme auf einer Anfragevariablen verursacht wird? Es wird durch einen Programmierfehler (Server) verursacht, ausgelöst durch die Anfrage (Client). Und was ist, wenn die Anfragevariable nicht von der Serverlogik benötigt wird, aber der Programmierer angenommen (also nicht geprüft) hat? Der springende Punkt ist: Die meisten Web-Frameworks geben beim Erkennen einer abnormalen Beendigung der Serversoftware 5xx-Codes zurück. Dieses Framework kann nicht zwischen einem Client- und einem Serverfehler als solchem ​​unterscheiden. – CodeCaster

+2

Stimmt, aber die Frage wurde im Zusammenhang mit dem Testen eines vermutlich neuen Dienstes und dem Einholen von Rückmeldungen darüber, wie die Situation letztlich behandelt werden sollte, formuliert. Wenn ich neue Dienste testen und 500 Testfälle für die Randfalleingabe generieren würde, würde ich dies als fehlgeschlagenen Test kennzeichnen und mit dem Entwickler zusammenarbeiten, um das Testszenario entweder mit einem beschreibenden Fehler (400, 404, etc) oder einem anderen Fehler zu behandeln ordnungsgemäß bediente Anfrage (200). Es gibt wirklich unvorhersehbare Quellen von 500 Fehlern, aber Sie können/sollten sich so gut wie möglich dagegen wehren, auch wenn das nur einen informativeren Fehler ergibt. – tokkov

2

Im Allgemeinen zeigen 5xx-Antwortcodes nicht programmatische Fehler an, z. B. einen Datenbankverbindungsfehler oder einen anderen System-/Bibliotheksabhängigkeitsfehler. In vielen Fällen wird erwartet, dass der Client dieselbe Anfrage in der Zukunft erneut einreichen kann und erwartet, dass sie erfolgreich ist.

Ja, einige Web-Frameworks antworten mit 5xx-Codes, aber diese sind in der Regel das Ergebnis von Fehlern im Code und das Framework ist zu abstrakt, um zu wissen, was passiert ist, so dass es standardmäßig auf diese Art von Antwort reagiert; Dieses Beispiel bedeutet jedoch nicht, dass wir die Angewohnheit haben sollten, 5xx-Codes als Ergebnis eines programmatischen Verhaltens zurückzugeben, das nichts mit Systemen außerhalb des Prozesses zu tun hat.Es gibt viele gut definierte Antwortcodes, die besser geeignet sind als die 5xx-Codes. Da es nicht möglich ist, eine gegebene Eingabe zu analysieren/zu validieren, handelt es sich nicht um eine 5xx-Antwort, da der Code eine geeignetere Antwort enthalten kann, die den Client nicht daran hindert, dieselbe Anforderung erneut zu übermitteln, obwohl dies tatsächlich nicht möglich ist.

Um klar zu sein, wenn der vom Server festgestellte Fehler auf CLIENT-Eingabe zurückzuführen war, handelt es sich eindeutig um einen CLIENT-Fehler, der mit einem 4xx-Antwortcode behandelt werden sollte. Es wird erwartet, dass der Kunde den Fehler in seiner Anfrage korrigiert und erneut einreicht.

Es ist jedoch völlig akzeptabel, alle Prozessfehler zu erfassen und sie als 5xx-Antwort zu interpretieren. Beachten Sie jedoch, dass Sie auch weitere Informationen in die Antwort aufnehmen müssen, um genau anzugeben, was fehlgeschlagen ist. und noch besser, wenn Sie SLA-Zeiten einbeziehen können.

Ich denke nicht, dass es eine gute Übung ist zu interpretieren, "ein unerwarteter Fehler" als 5xx Fehler, weil Bugs passieren.

Es ist ein häufiger Alert-Monitor, der bei 5xx-Fehlertypen zu alarmieren beginnt, da diese normalerweise fehlgeschlagene Systeme anstelle von fehlgeschlagenem Code anzeigen. Also, Code entsprechend!

3

Sie haben vorgeschlagen, "Unerwartete Fehler abzufangen und einige Fehlercodesignalisierung zurückzugeben" unerwartete Situation "", konnte jedoch keinen geeigneten Fehlercode finden.

Rate mal was: Das ist, wofür 5xx da ist.

0

80% der Zeit, würde dies durch

in soapRequest.xml Datei zu falschem Eingang zurückzuführen