400 vs 422 Antwort auf POST von Daten

Ich versuche herauszufinden, welcher Statuscode für verschiedene Szenarien mit einer "REST-ähnlichen" API, an der ich arbeite, der richtige ist. Angenommen, ich habe einen Endpunkt, der das POST-Kaufen im JSON-Format ermöglicht. Es sieht aus wie das:

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

Was soll ich zurückgeben, wenn der Kunde mir "sales_tax" sendet (anstelle der erwarteten "Steuer")? Derzeit gebe ich eine 400 zurück. Aber ich habe angefangen, mich dazu zu befragen. Sollte ich wirklich eine 422 zurückgeben? Ich meine, es ist JSON (das unterstützt wird) und es ist gültiges JSON, es enthält einfach nicht alle erforderlichen Felder.

400 Bad Request scheint nun der beste HTTP / 1.1-Statuscode für Ihren Anwendungsfall zu sein.

Zum Zeitpunkt Ihrer Frage (und meiner ursprünglichen Antwort) war RFC 7231 keine Sache. An diesem Punkt habe ich Einwände erhoben, 400 Bad Requestweil RFC 2616 sagte (mit Schwerpunkt auf meinem):

Die Anforderung konnte vom Server aufgrund einer fehlerhaften Syntax nicht verstanden werden .

und die von Ihnen beschriebene Anforderung ist syntaktisch gültiges JSON, das in syntaktisch gültigem HTTP eingeschlossen ist, und daher hat der Server keine Probleme mit der Syntax der Anforderung.

Wie Lee Saferite in den Kommentaren hervorhob , enthält RFC 7231, das RFC 2616 überholt, diese Einschränkung jedoch nicht :

Der Statuscode 400 (Bad Request) gibt an, dass der Server die Anforderung aufgrund eines als Clientfehler wahrgenommenen Fehlers nicht verarbeiten kann oder will (z. B. fehlerhafte Anforderungssyntax, ungültiges Anforderungsnachrichten-Framing oder irreführendes Anforderungsrouting).

Doch vor dieser Umformulierung (oder , wenn Sie über RFC 7231 nur Wortklauberei wollen ein Wesen vorgeschlagen Standard jetzt), 422 Unprocessable Entityscheint nicht einen falschen HTTP - Statuscode für Ihren Anwendungsfall, denn wie die Einführung in RFC 4918 sagt:

Während die von HTTP / 1.1 bereitgestellten Statuscodes ausreichen, um die meisten Fehlerbedingungen zu beschreiben, auf die WebDAV-Methoden stoßen, gibt es einige Fehler, die nicht genau in die vorhandenen Kategorien fallen. Diese Spezifikation definiert zusätzliche Statuscodes, die für WebDAV-Methoden entwickelt wurden (Abschnitt 11).

Und die Beschreibung von422 sagt:

Der Statuscode 422 (nicht verarbeitbare Entität) bedeutet, dass der Server den Inhaltstyp der Anforderungsentität versteht (daher ist ein 415-Statuscode (nicht unterstützter Medientyp) unangemessen) und die Syntax der Anforderungsentität korrekt ist (daher eine 400 (fehlerhafte Anforderung) ) Statuscode ist unangemessen) konnte die enthaltenen Anweisungen jedoch nicht verarbeiten.

(Beachten Sie den Verweis auf die Syntax; ich vermute, dass 7231 auch 4918 teilweise überholt hat)

Das klingt genau nach Ihrer Situation, aber für den Fall, dass Zweifel bestehen, heißt es weiter:

Diese Fehlerbedingung kann beispielsweise auftreten, wenn ein XML-Anforderungshauptteil wohlgeformte (dh syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

(Ersetzen Sie "XML" durch "JSON" und ich denke, wir können uns darauf einigen, dass dies Ihre Situation ist.)

Einige werden nun einwenden, dass es in RFC 4918 um "HTTP-Erweiterungen für das verteilte Web-Authoring und -Versionierung (WebDAV)" geht und dass Sie (vermutlich) nichts mit WebDAV zu tun haben und daher keine Dinge daraus verwenden sollten.

Angesichts der Wahl zwischen der Verwendung eines Fehlercodes im ursprünglichen Standard, der die Situation ausdrücklich nicht abdeckt, und eines aus einer Erweiterung, die die Situation genau beschreibt, würde ich letzteren wählen.

Darüber hinaus bezieht sich RFC 4918, Abschnitt 21.4, auf die HTTP-Statuscode-Registrierung (IANA Hypertext Transfer Protocol) , in der 422 zu finden ist.

Ich schlage vor, dass es für einen HTTP-Client oder -Server völlig vernünftig ist, einen Statuscode aus dieser Registrierung zu verwenden, sofern dies korrekt ist.

Aber ab HTTP / 1.1 hat RFC 7231 Traktion, also einfach verwenden 400 Bad Request!

400 Bad Request ist der richtige HTTP-Statuscode für Ihren Anwendungsfall. Der Code wird durch HTTP / 0.9-1.1 RFC definiert.

Die Anforderung konnte vom Server aufgrund einer fehlerhaften Syntax nicht verstanden werden. Der Client sollte die Anfrage NICHT ohne Änderungen wiederholen.

http://tools.ietf.org/html/rfc2616#section-10.4.1

422 Nicht verarbeitbare Entität wird von RFC 4918 - WebDav definiert. Beachten Sie, dass es im Vergleich zu 400 einen geringfügigen Unterschied gibt, siehe unten zitierten Text.

Diese Fehlerbedingung kann auftreten, wenn ein XML-Anforderungshauptteil wohlgeformte (dh syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

Um eine einheitliche Benutzeroberfläche zu erhalten, sollten Sie 422 nur bei XML-Antworten verwenden und alle Statuscodes unterstützen, die durch die Webdav-Erweiterung definiert sind, nicht nur 422.

http://tools.ietf.org/html/rfc4918#page-78

Siehe auch Mark Nottinghams Beitrag zu Statuscodes:

Es ist ein Fehler, zu versuchen, jeden Teil Ihrer Anwendung „tief“ in HTTP-Statuscodes abzubilden. In den meisten Fällen ist der Grad der Granularität, den Sie anstreben möchten, viel gröber. Im Zweifelsfall ist es in Ordnung, die generischen Statuscodes 200 OK, 400 Bad Request und 500 Internal Service Error zu verwenden, wenn keine bessere Anpassung vorliegt .

Wie man über HTTP-Statuscodes nachdenkt

Um den Status ab 2015 widerzuspiegeln:

Verhaltensmäßig werden sowohl 400 als auch 422 Antwortcodes von Kunden und Vermittlern gleich behandelt, sodass es keinen konkreten Unterschied macht, den Sie verwenden.

Ich würde jedoch erwarten, dass 400 derzeit in größerem Umfang verwendet werden, und die Klarstellungen, die die HTTPbis-Spezifikation enthält, machen sie außerdem zu einem der beiden Statuscodes:

• Die HTTPbis-Spezifikation verdeutlicht die Absicht von 400, nicht nur für Syntaxfehler zu gelten. Der breitere Ausdruck "zeigt an, dass der Server die Anforderung aufgrund eines als Clientfehler wahrgenommenen Fehlers nicht verarbeiten kann oder wird" wird jetzt verwendet.
• 422 ist speziell eine WebDAV-Erweiterung und wird in RFC 2616 oder in der neueren HTTPbis-Spezifikation nicht referenziert .

Für den Kontext ist HTTPbis eine Überarbeitung der HTTP / 1.1-Spezifikation, mit der versucht wird, Bereiche zu klären, die unklar oder inkonsistent sind. Sobald der genehmigte Status erreicht ist, wird RFC2616 ersetzt.

Fallstudie: GitHub API

https://developer.github.com/v3/#client-errors

Vielleicht ist das Kopieren von bekannten APIs eine kluge Idee:

Es gibt drei mögliche Arten von Clientfehlern bei API-Aufrufen, die Anforderungskörper empfangen:

Das Senden eines ungültigen JSON führt zu einer 400 Bad Request-Antwort.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

Das Senden des falschen Typs von JSON-Werten führt zu einer 400 Bad Request-Antwort.

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

Das Senden ungültiger Felder führt zu einer Antwort auf 422 nicht verarbeitbare Entitäten.

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

Es gibt keine richtige Antwort, da dies davon abhängt, wie die Definition von "Syntax" für Ihre Anfrage lautet. Das Wichtigste ist, dass Sie:

1. Verwenden Sie die Antwortcodes konsistent
2. Fügen Sie so viele zusätzliche Informationen wie möglich in den Antworttext ein, damit die Entwickler, die Ihre API verwenden, herausfinden können, was los ist. =

Bevor alle über mich hinwegspringen, weil sie sagen, dass es hier keine richtige oder falsche Antwort gibt, möchte ich kurz erläutern, wie ich zu dem Schluss gekommen bin.

In diesem speziellen Beispiel handelt es sich bei der Frage des OP um eine JSON-Anforderung, die einen anderen Schlüssel als erwartet enthält. Nun ist der empfangene Schlüsselname vom Standpunkt der natürlichen Sprache dem erwarteten Schlüssel sehr ähnlich, aber er unterscheidet sich streng und wird daher (normalerweise) von einer Maschine nicht als gleichwertig erkannt.

Wie ich oben sagte, ist der entscheidende Faktor, was unter Syntax zu verstehen ist . Wenn die Anforderung mit einem Inhaltstyp von gesendet wurde application/json, ist die Anforderung syntaktisch gültig, da sie eine gültige JSON-Syntax hat, jedoch nicht semantisch gültig, da sie nicht den Erwartungen entspricht. (unter der Annahme einer strengen Definition dessen, was die betreffende Anfrage semantisch gültig macht oder nicht).

Wenn andererseits die Anfrage mit einem spezifischeren benutzerdefinierten Inhaltstyp gesendet wurde application/vnd.mycorp.mydatatype+json, der möglicherweise genau angibt, welche Felder erwartet werden, würde ich sagen, dass die Anfrage leicht syntaktisch ungültig sein könnte, daher die 400-Antwort.

In dem Fall , in Frage, da der Schlüssel nicht in Ordnung war, nicht der Wert , gab es einen Syntaxfehler , wenn es eine Spezifikation war für das, was gültige Schlüssel. Wenn es keine Spezifikation für gültige Schlüssel gäbe oder der Fehler einen Wert hätte , wäre dies ein semantischer Fehler.

422 Nicht verarbeitbare Einheit erklärt Aktualisiert: 6. März 2017

Was ist eine nicht verarbeitbare Entität von 422?

Ein 422-Statuscode tritt auf, wenn eine Anforderung wohlgeformt ist, jedoch aufgrund semantischer Fehler nicht verarbeitet werden kann. Dieser HTTP-Status wurde in RFC 4918 eingeführt und ist insbesondere auf HTTP-Erweiterungen für Web Distributed Authoring und Versioning (WebDAV) ausgerichtet.

Es gibt einige Kontroversen darüber, ob Entwickler einen 400 vs 422-Fehler an Clients zurückgeben sollten oder nicht (mehr zu den Unterschieden zwischen beiden Status weiter unten). In den meisten Fällen wird jedoch vereinbart, dass der 422-Status nur zurückgegeben werden soll, wenn Sie WebDAV-Funktionen unterstützen.

Eine Wort-für-Wort-Definition des 422-Statuscodes aus Abschnitt 11.2 in RFC 4918 kann unten gelesen werden.

Der Statuscode 422 (nicht verarbeitbare Entität) bedeutet, dass der Server den Inhaltstyp der Anforderungsentität versteht (daher ist ein 415-Statuscode (nicht unterstützter Medientyp) unangemessen) und die Syntax der Anforderungsentität korrekt ist (daher eine 400 (fehlerhafte Anforderung) ) Statuscode ist unangemessen) konnte die enthaltenen Anweisungen jedoch nicht verarbeiten.

In der Definition heißt es weiter:

Diese Fehlerbedingung kann beispielsweise auftreten, wenn ein XML-Anforderungshauptteil wohlgeformte (dh syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

400 vs 422 Statuscodes

Fehlerhafte Anforderungsfehler verwenden den 400-Statuscode und sollten an den Client zurückgegeben werden, wenn die Anforderungssyntax fehlerhaft ist, einen ungültigen Anforderungsnachrichtenrahmen enthält oder ein irreführendes Anforderungsrouting aufweist. Dieser Statuscode scheint dem Status der nicht verarbeitbaren Entität 422 ziemlich ähnlich zu sein. Eine kleine Information, die sie unterscheidet, ist jedoch die Tatsache, dass die Syntax einer Anforderungsentität für einen 422-Fehler korrekt ist, während die Syntax einer Anforderung, die eine 400 generiert Fehler ist falsch.

Die Verwendung des Status 422 sollte nur für ganz bestimmte Anwendungsfälle reserviert werden. In den meisten anderen Fällen, in denen ein Clientfehler aufgrund einer fehlerhaften Syntax aufgetreten ist, sollte der Status 400 Bad Request verwendet werden.

https://www.keycdn.com/support/422-unprocessable-entity/

Ihr Fall: HTTP 400 ist der richtige Statuscode für Ihren Fall von REST Perspektive als syntaktisch falsch zu senden , sales_taxanstatt taxobwohl seine einer gültigen JSON. Dies wird normalerweise von den meisten serverseitigen Frameworks erzwungen, wenn der JSON Objekten zugeordnet wird. Es gibt jedoch einige REST-Implementierungen, die neue keyJSON-Objekte ignorieren . In diesem Fall kann eine benutzerdefinierte content-typeSpezifikation, die nur gültige Felder akzeptiert, serverseitig erzwungen werden.

Ideales Szenario für 422:

In einer idealen Welt wird 422 bevorzugt und im Allgemeinen als Antwort gesendet, wenn der Server den Inhaltstyp der Anforderungsentität versteht und die Syntax der Anforderungsentität korrekt ist, die Daten jedoch aufgrund ihrer semantischen Fehler nicht verarbeiten konnte.

Situationen von 400 über 422:

Denken Sie daran, dass der Antwortcode 422 ein erweiterter HTTP-Statuscode (WebDAV) ist. Es gibt immer noch einige HTTP-Clients / Front-End-Bibliotheken, die nicht für 422 vorbereitet sind. Für sie ist es so einfach wie "HTTP 422 ist falsch, weil es kein HTTP ist" . Aus Service-Sicht ist 400 nicht ganz spezifisch.

In der Unternehmensarchitektur werden die Dienste hauptsächlich auf Serviceebenen wie SOA, IDM usw. bereitgestellt. Sie bedienen normalerweise mehrere Clients, von einem sehr alten nativen Client bis zu einem neuesten HTTP-Client. Wenn einer der Clients nicht mit HTTP 422 umgehen kann, können Sie den Client auffordern, Ihren Antwortcode für alle Benutzer zu aktualisieren oder in HTTP 400 zu ändern. Nach meiner Erfahrung ist dies heutzutage sehr selten, aber immer noch eine Möglichkeit. Daher ist immer eine sorgfältige Untersuchung Ihrer Architektur erforderlich, bevor Sie sich für die HTTP-Antwortcodes entscheiden.

Um mit solchen Situationen fertig zu werden, verwenden die Service-Layer normalerweise das Flag versioningoder Setup configurationfür strikte HTTP-Konformitäts-Clients, um 400 und 422 für den Rest von ihnen zu senden. Auf diese Weise bieten sie Unterstützung für Abwärtskompatibilität für vorhandene Verbraucher, bieten aber gleichzeitig den neuen Clients die Möglichkeit, HTTP 422 zu verwenden.

Das neueste Update für RFC7321 lautet:

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

Dies bestätigt, dass Server HTTP 400 für eine ungültige Anforderung senden können. 400 bezieht sich nicht mehr nur auf Syntaxfehler , 422 ist jedoch immer noch eine echte Antwort, vorausgesetzt, die Clients können damit umgehen.

Erstens ist dies eine sehr gute Frage.

400 Bad Request - Wenn eine kritische Information in der Anfrage fehlt

zB Der Autorisierungsheader oder der Inhaltstypheader. Was vom Server unbedingt benötigt wird, um die Anfrage zu verstehen. Dies kann von Server zu Server unterschiedlich sein.

422 Nicht verarbeitbare Entität - Wenn der Anforderungshauptteil nicht analysiert werden kann.

Dies ist weniger schwerwiegend als 400. Die Anforderung hat den Server erreicht. Der Server hat bestätigt, dass die Anforderung die richtige Grundstruktur aufweist. Die Informationen im Anforderungshauptteil können jedoch nicht analysiert oder verstanden werden.

zB Content-Type: application/xmlwenn der Anfragetext JSON ist.

In diesem Artikel werden Statuscodes und ihre Verwendung in REST-APIs aufgelistet. https://metamug.com/article/status-codes-for-rest-api.php

Sie sollten tatsächlich "200 OK" zurückgeben und im Antworttext eine Nachricht darüber einfügen, was mit den veröffentlichten Daten passiert ist. Dann liegt es an Ihrer Anwendung, die Nachricht zu verstehen.

Die Sache ist, HTTP-Statuscodes sind genau das - HTTP-Statuscodes. Und diese sollen nur auf der Transportschicht eine Bedeutung haben, nicht auf der Anwendungsschicht. Die Anwendungsschicht sollte eigentlich nie wissen, dass HTTP verwendet wird. Wenn Sie Ihre Transportschicht von HTTP auf Brieftauben umgestellt haben, sollte dies keine Auswirkungen auf Ihre Anwendungsschicht haben.

Lassen Sie mich Ihnen ein nicht virtuelles Beispiel geben. Nehmen wir an, Sie verlieben sich in ein Mädchen und sie liebt Sie zurück, aber ihre Familie zieht in ein ganz anderes Land. Sie gibt dir ihre neue Postanschrift. Natürlich beschließen Sie, ihr einen Liebesbrief zu schicken. Also schreiben Sie Ihren Brief, stecken ihn in einen Umschlag, schreiben ihre Adresse auf den Umschlag, stempeln ihn ab und senden ihn ab. Betrachten wir nun diese Szenarien

1. Sie haben vergessen, einen Straßennamen zu schreiben. Sie erhalten einen ungeöffneten Brief mit einer Nachricht zurück, die besagt, dass die Adresse fehlerhaft ist. Sie haben die Anfrage vermasselt und die empfangende Post kann sie nicht bearbeiten. Das entspricht dem Erhalt von "400 Bad Request".
2. Sie legen also die Adresse fest und senden den Brief erneut. Aber aufgrund von Pech haben Sie den Straßennamen völlig falsch geschrieben. Sie erhalten den Brief erneut mit der Meldung zurück, dass die Adresse nicht vorhanden ist. Dies entspricht dem Empfang von "404 Not Found".
3. Sie korrigieren die Adresse erneut und schaffen es diesmal, die Adresse korrekt zu schreiben. Dein Mädchen erhält den Brief und schreibt dich zurück. Dies entspricht dem Erhalt von "200 OK". Dies bedeutet jedoch nicht, dass Ihnen gefallen wird, was sie in ihrem Brief geschrieben hat. Es bedeutet einfach, dass sie Ihre Nachricht erhalten hat und eine Antwort für Sie hat. Bis Sie den Umschlag öffnen und ihren Brief lesen, können Sie nicht wissen, ob sie Sie sehr vermisst oder mit Ihnen Schluss machen will.

Kurz gesagt: Die Rückgabe von "200 OK" bedeutet nicht, dass die Server-App gute Nachrichten für Sie hat. Es bedeutet nur, dass es einige Neuigkeiten gibt.

PS: Der 422-Statuscode hat nur im Kontext von WebDAV eine Bedeutung. Wenn Sie nicht mit WebDAV arbeiten, hat 422 genau die gleiche Standardbedeutung wie jeder andere nicht standardmäßige Code = der keine ist.