REST-HTTP-Statuscodes für fehlgeschlagene Validierung oder ungültiges Duplikat

Ich erstelle eine Anwendung mit einer REST-basierten API und bin an einem Punkt angelangt, an dem ich Statuscodes für jede Anforderung spezifiziere.

Welchen Statuscode sollte ich für Anfragen senden, bei denen die Validierung fehlschlägt oder bei denen eine Anfrage versucht, ein Duplikat in meine Datenbank aufzunehmen?

Ich habe http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html durchgesehen, aber keiner von ihnen scheint richtig zu sein.

Gibt es eine gängige Praxis beim Senden von Statuscodes?

Bei Fehler bei der Eingabevalidierung: 400 Bad Request + Ihre optionale Beschreibung. Dies wird im Buch " RESTful Web Services " vorgeschlagen. Für doppelte Einreichung: 409 Konflikt

Update Juni 2014

Die relevante Spezifikation war früher RFC2616 , was die Verwendung von 400 (Bad Request) eher eng als

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

Es könnte also argumentiert worden sein, dass es für semantische Fehler ungeeignet war. Aber nicht mehr; Seit Juni 2014 sieht der relevante Standard RFC 7231 , der den vorherigen RFC2616 ersetzt, die Verwendung von 400 (Bad Request) im weiteren Sinne vor

Der Server kann oder wird die Anforderung nicht verarbeiten, da dies als Clientfehler angesehen wird

• Fehlgeschlagene Validierung: 403 Verboten ("Der Server hat die Anforderung verstanden, weigert sich jedoch, sie zu erfüllen"). Entgegen der landläufigen Meinung sagt RFC2616 nicht "403 ist nur für fehlgeschlagene Authentifizierung vorgesehen", sondern "403: Ich weiß, was Sie wollen, aber das werde ich nicht tun". Diese Bedingung kann auf eine Authentifizierung zurückzuführen sein oder nicht.
• Versuch, ein Duplikat hinzuzufügen: 409 Konflikt ("Die Anforderung konnte aufgrund eines Konflikts mit dem aktuellen Status der Ressource nicht abgeschlossen werden.")

Sie sollten auf jeden Fall eine detailliertere Erklärung in den Antwortheadern und / oder im Text geben (z. B. mit einem benutzerdefinierten Header - X-Status-Reason: Validation failed).

Ich empfehle den Statuscode 422 "Nicht verarbeitbare Entität" .

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.

200.300, 400, 500 sind alle sehr allgemein. Wenn Sie generisch möchten, ist 400 in Ordnung.

422 wird von einer zunehmenden Anzahl von APIs verwendet und wird sogar von Rails sofort verwendet.

Unabhängig davon, welchen Statuscode Sie für Ihre API auswählen, wird jemand anderer Meinung sein. Aber ich bevorzuge 422, weil ich den '400 + Textstatus' für zu allgemein halte. Außerdem nutzen Sie keinen JSON-fähigen Parser. Im Gegensatz dazu ist ein 422 mit einer JSON-Antwort sehr explizit und es können viele Fehlerinformationen übermittelt werden.

Apropos JSON-Antwort: Ich tendiere dazu, die Rails-Fehlerantwort für diesen Fall zu standardisieren:

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

Dieses Format eignet sich perfekt für die Formularvalidierung, die meiner Meinung nach der komplexeste Fall ist, der im Hinblick auf die Fülle von Fehlerberichten unterstützt wird. Wenn Ihre Fehlerstruktur so ist, werden wahrscheinlich alle Ihre Fehlerberichterstattungsanforderungen erfüllt.

200

Ugh ... (309, 400, 403, 409, 415, 422) ... viele Antworten, die versuchen, den besten Rückkehrcode für eine erfolgreiche HTTP-Anforderung, aber einen fehlgeschlagenen REST-Aufruf zu erraten, zu argumentieren und zu standardisieren .

Es ist falsch , HTTP-Statuscodes und REST-Statuscodes zu mischen.

Ich habe jedoch viele Implementierungen gesehen, die sie gemischt haben, und viele Entwickler stimmen mir möglicherweise nicht zu.

HTTP-Rückkehrcodes beziehen sich auf sich HTTP Requestselbst. Ein REST-Aufruf wird mithilfe einer Hypertext Transfer Protocol-Anforderung ausgeführt und arbeitet auf einer niedrigeren Ebene als die aufgerufene REST-Methode selbst. REST ist ein Konzept / Ansatz, und seine Ausgabe ist ein geschäftliches / logisches Ergebnis, während der HTTP-Ergebniscode ein Transportergebnis ist .

Die Rückgabe von "404 nicht gefunden" beim Aufrufen von / users / ist beispielsweise verwirrend, da dies Folgendes bedeuten kann:

• URI ist falsch (HTTP)
• Es wurden keine Benutzer gefunden (REST)

"403 Verboten / Zugriff verweigert" kann bedeuten:

• Besondere Erlaubnis erforderlich. Browser können damit umgehen, indem sie den Benutzer / das Passwort fragen. (HTTP)
• Auf dem Server konfigurierte falsche Zugriffsberechtigungen. (HTTP)
• Sie müssen authentifiziert sein (REST)

Und die Liste kann mit '500 Server error' (ein Apache / Nginx HTTP-Fehler oder ein Business Constraint-Fehler in REST) ​​oder anderen HTTP-Fehlern usw. fortgesetzt werden.

Aus dem Code ist schwer zu verstehen, was der Fehlergrund, ein HTTP-Fehler (Transportfehler) oder ein REST-Fehler (logisch) war.

Wenn die HTTP-Anforderung physisch erfolgreich ausgeführt wurde, sollte immer 200 Code zurückgegeben werden, unabhängig davon, ob die Datensätze gefunden wurden oder nicht. Weil die URI-Ressource gefunden wurde und vom HTTP-Server verarbeitet wurde. Ja, möglicherweise wird ein leerer Satz zurückgegeben. Ist es möglich, eine leere Webseite mit 200 als HTTP-Ergebnis zu erhalten?

Stattdessen können Sie 200 HTTP-Code mit einigen Optionen zurückgeben:

• "Fehler" -Objekt in JSON-Ergebnis, wenn etwas schief geht
• Leeren Sie das JSON-Array / Objekt, wenn kein Datensatz gefunden wurde
• Ein Bool-Ergebnis- / Erfolgsflag in Kombination mit vorherigen Optionen für eine bessere Handhabung.

Einige Internetanbieter können Ihre Anfragen abfangen und Ihnen einen 404-HTTP-Code zurückgeben. Dies bedeutet nicht, dass Ihre Daten nicht gefunden werden, aber auf Transportebene stimmt etwas nicht.

Aus dem Wiki :

Im Juli 2004 setzte der britische Telekommunikationsanbieter BT Group das Cleanfeed-System zum Blockieren von Inhalten ein, das bei jeder Anforderung von Inhalten, die von der Internet Watch Foundation als potenziell illegal eingestuft wurden, einen 404-Fehler zurückgibt. Andere ISPs geben unter den gleichen Umständen einen "verbotenen" HTTP 403-Fehler zurück. In Thailand und Tunesien wurde auch über die Praxis berichtet, gefälschte 404-Fehler als Mittel zur Verschleierung der Zensur einzusetzen. In Tunesien, wo die Zensur vor der Revolution von 2011 streng war, wurden die Menschen auf die Natur der gefälschten 404-Fehler aufmerksam und schufen einen imaginären Charakter namens "Ammar 404", der "den unsichtbaren Zensor" darstellt.

Warum nicht einfach mit so etwas antworten?

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google gibt in seiner Geokodierungs-API immer 200 als Statuscode zurück, auch wenn die Anforderung logisch fehlschlägt: https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Facebook gibt für erfolgreiche HTTP-Anforderungen immer 200 zurück, auch wenn die REST-Anforderung fehlschlägt: https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

Es ist ganz einfach, HTTP-Statuscodes gelten für HTTP-Anforderungen. Die REST-API ist Ihre, definieren Sie Ihre Statuscodes.

Ein Duplikat in der Datenbank sollte a sein 409 CONFLICT.

Ich empfehle die Verwendung 422 UNPROCESSABLE ENTITYfür Validierungsfehler.

Ich gebe eine längere Erklärung von 4xx - Codes hier .

Der Statuscode 304 Nicht geändert würde auch eine akzeptable Antwort auf eine doppelte Anfrage geben. Dies ähnelt der Verarbeitung eines Headers zur If-None-MatchVerwendung eines Entity-Tags.

Meiner Meinung nach ist die Antwort von @ Piskvor die offensichtlichere Wahl für das, was ich als Absicht der ursprünglichen Frage empfinde, aber ich habe eine Alternative, die ebenfalls relevant ist.

Wenn Sie eine doppelte Anforderung als Warnung oder Benachrichtigung und nicht als Fehler behandeln möchten, ist der Antwortstatuscode 304Nicht geändert und der Content-LocationHeader, der die vorhandene Ressource identifiziert, genauso gültig. Wenn lediglich sichergestellt werden soll, dass eine Ressource vorhanden ist, ist eine doppelte Anforderung kein Fehler, sondern eine Bestätigung. Die Anforderung ist nicht falsch, sondern einfach redundant, und der Client kann auf die vorhandene Ressource verweisen.

Mit anderen Worten, die Anforderung ist gut, aber da die Ressource bereits vorhanden ist, muss der Server keine weitere Verarbeitung durchführen.

Der ActiveRecord-Adapter von Ember-Data wird voraussichtlich 422 UNPROCESSABLE ENTITYvom Server zurückgegeben. Wenn Ihr Client in Ember.js geschrieben ist, sollten Sie 422 verwenden. Nur dann werden DS.Errors mit zurückgegebenen Fehlern gefüllt. Sie können 422 natürlich in einen anderen Code in Ihrem Adapter ändern .