Was ist ein geeigneter HTTP-Statuscode, der von einem REST-API-Dienst bei einem Validierungsfehler zurückgegeben wird?

Question

Ich gebe derzeit 401 Unauthorized zurück, wenn ich einen Validierungsfehler in meinem Django / Kolben basierte REST-API-Anwendung. Nachdem wir einen Blick auf die HTTP-Statuscode-Register Ich bin nicht überzeugt, dass dies ein geeigneter Code für einen Validierungsfehler ist, was empfehlen Sie?

• 400 Schlechte Anfrage
• 401 Unerlaubt
• 403 Verboten
• 405 Nicht erlaubte Methode
• 406 Nicht akzeptabel
• 412 Vorbedingung fehlgeschlagen
• 417 Erwartung nicht erfüllt
• 422 Unverarbeitbare Entität
• 424 Fehlgeschlagene Dependenz

Update : Mit "Validierungsfehler" ist ein Fehler bei der Datenvalidierung auf Anwendungsebene gemeint, z. B. ein falsch angegebenes Datum, eine gefälschte E-Mail-Adresse usw.

Answer 1

Wenn "Validierungsfehler" bedeutet, dass ein Client-Fehler in der Anfrage vorliegt, dann verwenden Sie HTTP 400 (Bad Request). Wenn der URI beispielsweise ein ISO-8601-Datum enthalten soll und Sie feststellen, dass es im falschen Format vorliegt oder sich auf den 31. Februar bezieht, dann würden Sie eine HTTP 400 zurückgeben. Das Gleiche gilt, wenn Sie wohlgeformtes XML in einem Entity-Body erwarten und dieser nicht geparst werden kann.

(1/2016): In den letzten fünf Jahren WebDAV Das spezifischere HTTP 422 (Unprocessable Entity) hat sich zu einer sehr vernünftigen Alternative zu HTTP 400 entwickelt. Siehe zum Beispiel seine Verwendung in JSON-API . Beachten Sie jedoch, dass HTTP 422 eine no hat es in HTTP 1.1 geschafft, RFC-7231 .

Richardson und Ruby's RESTful Webdienste enthält einen sehr hilfreichen Anhang darüber, wann die verschiedenen HTTP-Antwortcodes zu verwenden sind. Dort heißt es:

400 ("Schlechte Anfrage")
Wichtigkeit: Hoch.
Dies ist der allgemeine client-seitige Fehlerstatus, der verwendet wird, wenn kein anderer 4xx-Fehlercode geeignet ist. Er wird üblicherweise verwendet, wenn der Client eine Darstellung zusammen mit einer PUT- oder POST-Anfrage übermittelt und die Darstellung zwar das richtige Format hat, aber keinen keinen Sinn. (p. 381)

und:

401 ("Nicht autorisiert")
Wichtigkeit: Hoch.
Der Client hat versucht, auf eine geschützte Ressource zuzugreifen, ohne die richtigen Authentifizierungsdaten anzugeben. Möglicherweise hat er die falschen oder gar keine Anmeldedaten angegeben. Die Anmeldeinformationen können ein Benutzername und ein Passwort, ein API-Schlüssel oder ein Authentifizierungs-Token sein. Token sein - was auch immer der betreffende Dienst erwartet. Es ist üblich, dass ein Client eine Anfrage für einen URI stellt und ein 401 akzeptiert, nur damit er weiß, welche Art von Anmeldeinformationen er senden muss und in welchem Format. [...]

Answer 2

Aus RFC 4918 (und auch dokumentiert unter http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ):

Der Statuscode 422 (Unprocessable Entity) bedeutet, dass der Server den Inhaltstyp der angeforderten Entität versteht (daher ist ein 415 (Unsupported Media Type)-Statuscode ist unangemessen), und die Syntax der Anforderungseinheit korrekt ist (daher ist ein 400 (Bad Request) Statuscode unangemessen ist), aber die enthaltenen Anweisungen nicht verarbeiten Anweisungen zu verarbeiten. Diese Fehlerbedingung kann zum Beispiel auftreten, wenn ein XML Request Body wohlgeformte (d.h. syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

Answer 3

Ein Duplikat in der Datenbank sollte ein 409 CONFLICT .

Ich empfehle die Verwendung von 422 UNPROCESSABLE ENTITY für Validierungsfehler.

Ich gebe hier eine längere Erklärung der 4xx-Codes: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

Answer 4

Hier ist sie:

rfc2616#section-10.4.1 - 400 Bad Request

Die Anfrage konnte vom Server nicht verstanden werden aufgrund von missgestaltet Syntax . Der Client SOLLTE die Anfrage NICHT unverändert wiederholen.

rfc7231#section-6.5.1 - 6.5.1. 400 Schlechte Anfrage

Der Statuscode 400 (Bad Request) zeigt an, dass der Server die Anfrage nicht die Anfrage nicht bearbeiten kann oder will, weil sie als Client-Fehler wahrgenommen wird als Client-Fehler angesehen wird (z. B. fehlerhafte Anfragesyntax, ungültiges Framing von Anfragemeldungen oder betrügerische Weiterleitung von Anfragen) .

Bezieht sich auf missgebildete (nicht wohlgeformte) Fälle!

rfc4918 - 11.2. 422 Unverarbeitbare Entität

Der Statuscode 422 (Unprocessable Entity) bedeutet, dass der Server
den Inhaltstyp der Anforderungsentität versteht (daher ist ein Statuscode 415 (Unsupported Media Type) unangemessen), und die die Syntax der Anfrageeinheit korrekt ist (daher ist ein Statuscode 400 (Bad Request) unangebracht), konnte aber die enthaltenen Anweisungen nicht verarbeiten. Diese Fehlerbedingung kann zum Beispiel auftreten, wenn ein XML-Anfragekörper wohlgeformte (d.h. syntaktisch korrekte), aber semantisch fehlerhaft , XML-Anweisungen.

Schlussfolgerung

Faustregel: [_]00 deckt den allgemeinsten Fall und Fälle ab, die nicht durch einen bestimmten Code abgedeckt sind.

422 passt am besten Objekt Validierung Fehler (genau meine Empfehlung:)
In Bezug auf semantisch inkorrekt - Denken Sie an so etwas wie eine "Dieser Benutzername existiert bereits"-Überprüfung.

400 wird fälschlicherweise für die Objektvalidierung verwendet

Answer 5

Ich würde sagen, dass es sich technisch gesehen nicht um einen HTTP-Fehler handelt, da die Ressource (vermutlich) gültig angegeben wurde, der Benutzer authentifiziert war und kein Betriebsfehler vorlag (allerdings enthält auch die Spezifikation einige reservierte Codes wie 402 Payment Required, die streng genommen auch nicht mit HTTP zusammenhängen, obwohl es ratsam sein könnte, dies auf Protokollebene festzulegen, damit jedes Gerät den Zustand erkennen kann).

Wenn das tatsächlich der Fall ist, würde ich der Antwort ein Statusfeld mit Anwendungsfehlern hinzufügen, etwa

<status><code>4</code><message>Datumsbereich ist ungültig</message></status>