Was ist ein geeigneter HTTP-Statuscode, der von einem REST-API-Service für einen Validierungsfehler zurückgegeben werden kann?

Ich gebe derzeit 401 Unauthorized zurück, wenn in meiner Django / Piston- basierten REST-API-Anwendung ein Validierungsfehler auftritt. Nachdem ich mir die Registrierung des HTTP- Statuscodes angesehen habe, bin ich nicht davon überzeugt, dass dies ein geeigneter Code für einen Validierungsfehler ist. Was empfehlen Sie?

• 400 schlechte Anfrage
• 401 nicht Autorisiert
• 403 Verboten
• 405 Methode nicht zulässig
• 406 Nicht akzeptabel
• 412 Voraussetzung fehlgeschlagen
• 417 Erwartung fehlgeschlagen
• 422 Nicht verarbeitbare Entität
• 424 Fehlgeschlagene Abhängigkeit

Update : "Validierungsfehler" oben bedeutet einen Datenvalidierungsfehler auf Anwendungsebene, dh falsch angegebene Datums- und Uhrzeitangaben, falsche E-Mail-Adressen usw.

Wenn "Validierungsfehler" bedeutet, dass die Anforderung einen Clientfehler enthält, verwenden Sie HTTP 400 (Bad Request). Wenn der URI beispielsweise ein ISO-8601-Datum haben soll und Sie feststellen, dass er im falschen Format vorliegt oder sich auf den 31. Februar bezieht, geben Sie einen HTTP 400 zurück. Das Gleiche gilt, wenn Sie wohlgeformtes XML in einem Entitätskörper und erwarten es kann nicht analysiert werden.

(1/2016): In den letzten fünf Jahren hat sich WebDAVs spezifischeres HTTP 422 (Unprocessable Entity) zu einer sehr vernünftigen Alternative zu HTTP 400 entwickelt. Siehe beispielsweise die Verwendung in der JSON-API . Beachten Sie jedoch, dass HTTP 422 es nicht in HTTP 1.1, RFC-7231 geschafft hat .

Die RESTful Web Services von Richardson und Ruby enthalten einen sehr hilfreichen Anhang zur Verwendung der verschiedenen HTTP-Antwortcodes. Man sagt:

400 ("Bad Request")
Bedeutung: Hoch.
Dies ist der generische clientseitige Fehlerstatus, der verwendet wird, wenn kein anderer 4xx-Fehlercode geeignet ist. Es wird häufig verwendet, wenn der Client eine Darstellung zusammen mit einer PUT- oder POST-Anforderung sendet und die Darstellung im richtigen Format vorliegt, aber keinen Sinn ergibt. (S. 381)

und:

401 ("Nicht autorisiert")
Bedeutung: Hoch.
Der Client hat versucht, eine geschützte Ressource zu bearbeiten, ohne die richtigen Authentifizierungsdaten anzugeben. Möglicherweise wurden die falschen oder gar keine Anmeldeinformationen angegeben. Die Anmeldeinformationen können ein Benutzername und ein Kennwort, ein API-Schlüssel oder ein Authentifizierungstoken sein - unabhängig davon, was der betreffende Dienst erwartet. Es ist üblich, dass ein Client eine Anforderung für einen URI stellt und einen 401 akzeptiert, nur damit er weiß, welche Art von Anmeldeinformationen gesendet werden sollen und in welchem ​​Format. [...]

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

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. Diese Fehlerbedingung kann beispielsweise auftreten, wenn ein XML-Anforderungshauptteil wohlgeformte (dh syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

Ein Duplikat in der Datenbank sollte a sein 409 CONFLICT.

Ich empfehle die Verwendung 422 UNPROCESSABLE ENTITYfü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/

Hier ist es:

rfc2616 # section-10.4.1 - 400 Bad Request

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

rfc7231 # section-6.5.1 - 6.5.1. 400 schlechte Anfrage

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) .

Bezieht sich auf fehlerhafte (nicht gut geformte) Fälle!

rfc4918 - 11.2. 422 Nicht verarbeitbare Entität

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. Diese Fehlerbedingung kann beispielsweise auftreten, wenn ein XML-Anforderungshauptteil wohlgeformte (dh syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

Fazit

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

422 passt am besten zum Fehler bei der Objektvalidierung (genau meine Empfehlung :)
Was semantisch fehlerhafte Fehler betrifft - Denken Sie an die Validierung "Dieser Benutzername existiert bereits".

400 wird fälschlicherweise zur Objektvalidierung verwendet

Ich würde sagen, dass es sich technisch gesehen möglicherweise nicht um einen HTTP-Fehler handelt, da die Ressource (vermutlich) gültig angegeben wurde, der Benutzer authentifiziert wurde und kein Betriebsfehler aufgetreten ist (selbst die Spezifikation enthält jedoch einige reservierte Codes wie 402 Payment Required, die nicht vorhanden sind). t streng genommen auch HTTP-bezogen, obwohl es ratsam sein kann, dies auf Protokollebene zu haben, damit jedes Gerät den Zustand erkennen kann).

Wenn dies tatsächlich der Fall ist, würde ich der Antwort ein Statusfeld mit Anwendungsfehlern hinzufügen, wie z

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

In RFC 2616 , in dem HTTP 1.1 dokumentiert ist, finden Sie weitere Informationen zur Semantik dieser Fehler .

Persönlich würde ich wahrscheinlich verwenden 400 Bad Request, aber dies ist nur meine persönliche Meinung ohne sachliche Unterstützung.

Was genau meinen Sie mit "Validierungsfehler"? Was validierst du? Beziehen Sie sich auf einen Syntaxfehler (z. B. fehlerhaftes XML)?

Wenn das der Fall ist, würde ich sagen, dass 400 Bad Request wahrscheinlich das Richtige ist, aber ohne zu wissen, was Sie "validieren", ist es unmöglich zu sagen.