REST-Antwortcode für ungültige Daten

Welcher Antwortcode sollte in folgenden Szenarien an den Client übergeben werden?

1. Bei der Benutzerregistrierung wurden ungültige Daten wie falsches E-Mail-Format übergeben
2. Benutzername / E-Mail ist bereits vorhanden

Ich habe 403 gewählt. Ich habe auch festgestellt, dass ich das Gefühl habe, verwendet werden zu können.

Wikipedia:

412 Voraussetzung fehlgeschlagen: Der Server erfüllt nicht eine der Voraussetzungen, die der Anforderer für die Anforderung gestellt hat

Schlagen Sie Code vor, wenn ich einen anderen als 403 verwenden soll.

400 ist in beiden Fällen die beste Wahl. Wenn Sie den Fehler weiter klären möchten, können Sie entweder die Begründungsphrase ändern oder einen Text einfügen, um den Fehler zu erklären.

412 - Die Bedingung "Fehlgeschlagen" wird für bedingte Anforderungen verwendet, wenn das Datum der letzten Änderung und ETags verwendet werden.

403 - Verboten wird verwendet, wenn der Server den Zugriff auf eine Ressource verhindern möchte.

Die einzige andere Möglichkeit, die möglich ist, ist 422 - Nicht verarbeitbare Entität.

Ich würde 422 empfehlen. Es ist nicht Teil der HTTP-Hauptspezifikation, aber es wird durch einen öffentlichen Standard (WebDAV) definiert und sollte von Browsern genauso behandelt werden wie jeder andere 4xx-Statuscode.

Aus RFC 4918 :

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.

Wenn die Anforderung nicht korrekt analysiert werden konnte (einschließlich der Anforderungsentität / des Hauptteils), lautet die entsprechende Antwort 400 Bad Request [ 1 ].

RFC 4918 besagt, dass 422 Unprocessable Entity anwendbar ist, wenn die Anforderungsentität syntaktisch wohlgeformt, aber semantisch fehlerhaft ist. Wenn die Anforderungsentität verstümmelt ist (wie ein schlechtes E-Mail-Format), verwenden Sie 400; aber wenn es einfach keinen Sinn macht (wie @example.com), benutze 422.

Wenn das Problem darin besteht, dass, wie in der Frage angegeben, Benutzername / E-Mail bereits vorhanden ist, können Sie 409 Conflict [ 2 ] mit einer Beschreibung des Konflikts und einem Hinweis zur Behebung des Konflikts verwenden (in diesem Fall "Wählen Sie eine aus" anderer Benutzername / E-Mail "). In der angegebenen Spezifikation kann jedoch auch in diesem Fall 403 Forbidden [ 3 ] verwendet werden, ungeachtet der Argumente zur HTTP-Autorisierung.

412 Vorbedingung fehlgeschlagen [ 4 ] wird verwendet, wenn ein vom Client bereitgestellter Vorbedingungsanforderungsheader (z. B. If-Match) als falsch ausgewertet wird. Das heißt, der Kunde forderte etwas an und lieferte die Voraussetzungen, wobei er genau wusste, dass diese Voraussetzungen möglicherweise fehlschlagen. 412 sollte nie auf dem Client aus heiterem Himmel entstanden sein und nicht auf die Anfrage Einheit in Beziehung gesetzt werden sollte per se .

Es ist amüsant, 418 I'm a teapotzu Anforderungen zurückzukehren, die offensichtlich manipuliert oder böswillig sind und "nicht passieren" können, z. B. fehlgeschlagene CSRF-Prüfung oder fehlende Anforderungseigenschaften.

2.3.2 418 Ich bin eine Teekanne

Jeder Versuch, Kaffee mit einer Teekanne zuzubereiten, sollte den Fehlercode "418 Ich bin eine Teekanne" ergeben. Der resultierende Entitätskörper kann kurz und kräftig sein.

Um es einigermaßen ernst zu halten, beschränke ich die Verwendung lustiger Fehlercodes auf RESTful-Endpunkte, die dem Benutzer nicht direkt zugänglich sind.