it-swarm.com.de

REST Antwortcode für ungültige Daten

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

  1. Ungültige Daten bei der Benutzerregistrierung wie falsches E-Mail-Format
  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 Vorbedingung fehlgeschlagen: Der Server erfüllt nicht eine der Voraussetzungen, die der Anforderer für die Anforderung festgelegt hat

Schlagen Sie Code vor, wenn ich andere als 403 verwenden sollte.

260
Amit Patel

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

412 - Vorbedingung 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 Auswahlmöglichkeit ist 422 - Nicht verarbeitbare Entität.

279
Darrel Miller

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

Von RFC 4918 :

Der Statuscode 422 (Nicht verarbeitbare Entität) bedeutet, dass der Server den Inhaltstyp der Anforderungsentität versteht (daher ist ein Statuscode 415 (Nicht unterstützter Medientyp) ungeeignet) und die Syntax der Anforderungsentität korrekt ist (daher eine 400 (ungültige Anforderung) ) Der Statuscode ist unangemessen.) Die enthaltenen Anweisungen konnten jedoch nicht verarbeitet werden. Diese Fehlerbedingung kann beispielsweise auftreten, wenn ein XML-Anforderungstext wohlgeformte (d. H. Syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

90
Mike Deck

Wenn die Anfrage nicht korrekt analysiert werden konnte (einschließlich der Entität/des Körpers der Anfrage), lautet die entsprechende Antwort 400 Bad Request [ 1 ].

RFC 4918 gibt an, dass 422 Nicht verarbeitbare Entität anwendbar ist, wenn die Anforderungsentität syntaktisch korrekt, aber semantisch fehlerhaft ist. Wenn die Anforderungsentität also verstümmelt ist (wie bei einem schlechten E-Mail-Format), verwenden Sie 400; aber wenn es einfach keinen Sinn ergibt (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 verwenden =] mit einer Beschreibung des Konflikts und einem Hinweis zur Behebung des Konflikts (in diesem Fall "Wählen Sie einen anderen Benutzernamen/eine andere E-Mail-Adresse"). In der angegebenen Spezifikation kann jedoch 403 Forbidden [] auch in diesem Fall verwendet werden, ungeachtet der Argumente zur HTTP-Autorisierung .

412 Vorbedingung fehlgeschlagen [ 4 ] wird verwendet, wenn ein Vorbedingungs-Anforderungsheader (z. B. If-Match) das war vom Client geliefert ergibt false. Das heißt, der Client hat etwas angefordert und die Voraussetzungen angegeben, wobei er genau wusste, dass diese Voraussetzungen möglicherweise fehlschlagen. 412 sollte niemals aus heiterem Himmel auf den Client geworfen werden und sollte nicht mit der Anforderungsentität in Beziehung stehen per se.

79
Matty K

Es ist amüsant, zurückzukehren 418 I'm a teapot für Anforderungen, 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 I'm a teekanne" ergeben. Der resultierende Entitätskörper KANN kurz und fest 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.

39
doug65536