it-swarm.com.de

Rückgabe von http 200 OK mit Fehler im Antworttext

Ich frage mich, ob es korrekt ist, HTTP 200 OK zurückzugeben, wenn ein Fehler auf dem Server mit einem Fehler im Antworttext aufgetreten ist.

Beispiel:

  1. Wir senden http GET
  2. Auf der Serverseite ist etwas Unerwartetes passiert.
  3. Server gibt http 200 OK-Statuscode mit Fehler in einer Antwort zurück (z. B. {"status":"some error occured"}

Ist das richtige Verhalten oder nicht? Sollten wir den Statuscode nicht ändern? 

48
krzakov

Nein, das ist sehr falsch.

HTTP ist ein Anwendungsprotokoll. 200 bedeutet, dass die Antwort eine Nutzlast enthält, die den Status der angeforderten Ressource darstellt. Eine Fehlermeldung ist normalerweise keine Darstellung dieser Ressource.

Wenn während der Verarbeitung von GET etwas schief geht, lautet der richtige Statuscode 4xx ("Sie haben sich durcheinander gebracht") oder 5xx ("Ich habe durcheinander").

67
Julian Reschke

HTTP-Statuscodes sagen etwas über das HTTP-Protokoll aus. HTTP 200 bedeutet, dass die Übertragung auf HTTP-Ebene in Ordnung ist (d. h. die Anforderung war technisch in Ordnung und der Server konnte ordnungsgemäß antworten). Siehe diese Wiki-Seite für eine Liste aller Codes und ihrer Bedeutung. 

HTTP 200 hat nichts mit dem Erfolg oder Misserfolg Ihres "Geschäftscodes" zu tun. In Ihrem Beispiel ist der HTTP 200 ein akzeptabler Status, um anzuzeigen, dass Ihre "Geschäftscodefehlermeldung" erfolgreich übertragen wurde, vorausgesetzt, dass die Geschäftslogik nicht durch technische Probleme ordnungsgemäß ausgeführt wurde.

Alternativ können Sie Ihren Server mit HTTP 5xx antworten lassen, wenn technische oder nicht behebbare Probleme auf dem Server aufgetreten sind. Oder HTTP 4xx, wenn bei der eingehenden Anforderung Probleme aufgetreten sind (z. B. falsche Parameter, unerwartete HTTP-Methode ...) Auch dies weist auf Fehler technical hin, während HTTP 200KEINE technische Fehler anzeigt, jedoch keine Garantie dafür gibt Fehler in der Geschäftslogik.

Zusammenfassend: JA Es ist gültig, Fehlermeldungen (für nicht technische Probleme) in Ihrer http-Antwort zusammen mit dem HTTP-Status 200 zu senden. Ob dies auf Ihren Fall zutrifft, liegt bei Ihnen. Wenn der Client beispielsweise nach einer Datei fragt, die nicht vorhanden ist, wäre dies eher ein 404. Wenn auf dem Server eine falsche Konfiguration vorliegt, kann dies ein 500 sein. Wenn der Kunde nach einem Sitzplatz in einem voll gebuchten Flugzeug fragt, wäre dies 200 und Ihre "Implementierung" bestimmt, wie dies erkannt/behandelt werden soll (z. B. JSON-Block mit einem { "booking","failed" }).

17
geert3

Selbst wenn ich einen Geschäftslogikfehler als HTTP-Code zurückgeben möchte, gibt es keinen solchen Akzeptablen HTTP-Fehlercode für diesen Fehler, anstatt HTTP 200 zu verwenden, da er den tatsächlichen Fehler falsch darstellt.

HTTP 200 ist also gut für Geschäftslogikfehler. Alle Fehler, die durch HTTP-Fehlercodes abgedeckt werden, sollten sie jedoch verwenden.

Grundsätzlich bedeutet HTTP 200, welcher Server die Benutzeranfragen korrekt verarbeitet (falls keine Sitze im Flugzeug vorhanden sind, ist es egal, ob die Benutzeranfragen korrekt verarbeitet wurden), es kann sogar nur eine Anzahl von verfügbaren Plätzen im Flugzeug zurückgegeben werden Es können keine Geschäftslogikfehler oder diese Geschäftslogik auf der Clientseite auftreten. Der Geschäftslogikfehler ist eine abstrakte Bedeutung, der HTTP-Fehler ist jedoch eindeutiger.

7
Alexanderius

Um dies zu verdeutlichen, sollten Sie HTTP-Fehlercodes verwenden, wo sie zum Protokoll passen, und HTTP-Statuscodes nicht zum Senden von business logic -Fehlern verwenden.

Fehler wie unzureichende Balance, keine Kabinen verfügbar, falscher Benutzer/Passwort sind für den HTTP-Status 200 mit anwendungsspezifischer Fehlerbehandlung im Antworttext qualifiziert.

Siehe diese Software-Engineering-Antwort :

Ich würde sagen, dass es besser ist, die Trennung der Protokolle explizit zu beschreiben. Lassen Sie den HTTP-Server und den Webbrowser ihr eigenes Ding, und lassen Sie die App ihr sein eigenes Ding tun. Die App muss in der Lage sein, Anfragen zu stellen, und sie braucht die Antworten - und ihre Logik, wie sie angefordert werden, wie die Antworten zu interpretieren sind, kann komplexer (oder weniger) als die HTTP-Perspektive sein.

4
vedant

HTTP Ist das Protokoll, das die Übertragung von Daten über das Internet abwickelt. 

Wenn diese Übertragung aus irgendeinem Grund unterbrochen wird, zeigen die HTTP-Fehlercodes an, warum sie nicht an Sie gesendet werden können. 

Die übertragenen Daten werden nicht von HTTP-Fehlercodes verarbeitet. Nur die Übertragungsart. 

HTTP kann nicht sagen "Ok, diese Antwort ist gobbledigook, aber hier ist es". es sagt nur 200 OK

das heißt: Ich habe meine Aufgabe erfüllt, es Ihnen zu bringen, der Rest liegt bei Ihnen.

Ich weiß, dass dies bereits beantwortet wurde, aber ich habe es in Worten ausgedrückt, die ich verstehen kann. Entschuldigung für jede Wiederholung.

1
Chris Groves

Ich denke, die Leute haben der Anwendungslogik gegenüber der Protokollsache zu viel Gewicht beigemessen. Wichtig ist, dass die Antwort sinnvoll ist. Was ist, wenn Sie über eine API verfügen, die eine dynamische Ressource bedient, und eine Anforderung für X erfolgt, die aus der Vorlage Y mit den Daten Z abgeleitet wird und entweder Y oder Z derzeit nicht verfügbar ist? Ist das ein Fehler in der Geschäftslogik oder ein technischer Fehler? Die richtige Antwort lautet: "Wen interessiert das?"

Ihre API und Ihre Antworten müssen verständlich und konsistent sein. Es sollte einer Art Spezifikation entsprechen und diese Spezifikation sollte definieren, was eine gültige Antwort ist. Etwas, das einer gültigen Antwort entspricht, sollte einen 200-Code ergeben. Etwas, das nicht mit einer gültigen Antwort übereinstimmt, sollte einen 4xx- oder 5xx-Code ergeben, der angibt, warum eine gültige Antwort nicht generiert werden konnte.

Wenn die Definition Ihrer Spezifikation für eine gültige Antwort { "error": "invalid ID" } Zulässt, ist die Antwort erfolgreich. Wenn Ihre Spezifikation diese Anpassung nicht vornimmt, wäre es eine schlechte Entscheidung, diese Antwort mit einem 200-Code zurückzugeben.

Ich würde eine Analogie zum Aufrufen einer Funktion parseFoo ziehen. Was passiert, wenn Sie parseFoo("invalid data") aufrufen? Gibt es ein Fehlerergebnis zurück (möglicherweise null)? Oder wirft es eine Ausnahme? Viele werden eine fast religiöse Haltung einnehmen, ob der eine oder der andere Ansatz richtig ist, aber letztendlich liegt es an der API-Spezifikation.

"Das Status-Code-Element ist ein dreistelliger Integer-Code, der das Ergebnis des Versuchs angibt, die Anforderung zu verstehen und zu erfüllen."

Offensichtlich gibt es Meinungsverschiedenheiten darüber, ob "erfolgreich ein Fehler zurückgegeben" ein HTTP-Erfolg oder ein HTTP-Fehler ist. Ich sehe verschiedene Leute, die die gleichen Spezifikationen unterschiedlich interpretieren. Suchen Sie sich also eine Seite aus, aber akzeptieren Sie auch, dass die ganze Welt Ihnen nicht zustimmen wird. Mich? Ich befinde mich irgendwo in der Mitte, aber ich werde einige vernünftige Überlegungen anstellen.

  1. Wenn Ihr serverseitiger Code beim Senden einer Anfrage eine unerwartete Ausnahme feststellt, klingt dies wie die Definition eines 500 Internal Server Error. Dies scheint die Situation von OP zu sein. Die Anwendung sollte bei unerwarteten Fehlern kein 200 Zurückgeben. Siehe auch Punkt 3.
  2. Wenn Ihr serverseitiger Code eine bestimmte ungültige Eingabe ordnungsgemäß verarbeiten kann und keine "außergewöhnliche" Fehlerbedingung darstellt, sollte Ihre Spezifikation bieten Platz für HTTP 200-Antworten, die aussagekräftige Diagnoseinformationen liefern.
  3. Vor allem: Haben Sie eine Spezifikation. Machen Sie es konsistent. Halten Sie sich daran.

In der Situation von OP klingt es so, als hätten Sie einen De-facto-Standard, bei dem nicht behandelte Ausnahmen 200 mit einem unterscheidbaren Antworttext ergeben. Es ist nicht ideal, aber wenn es nicht die Dinge kaputt macht und aktiv Probleme verursacht, müssen Sie wahrscheinlich größere, wichtigere Probleme lösen.

0
snarf