400 Schlechte Anforderung. Was bedeutet der HTTP-Fehlercode?

Question

Ich habe eine JSON-Anfrage, die ich an eine HTTP-URL poste.

Sollte dies als 400 behandelt werden, wenn das requestedResource-Feld vorhanden ist, aber "Roman" ein ungültiger Wert für dieses Feld ist?

[{requestedResource:"Roman"}] 

Sollte dies als 400 behandelt werden, wenn das "blah"-Feld überhaupt nicht existiert?

[{blah:"Roman"}]

Answer 1

Ein 400 bedeutet, dass die Anfrage fehlerhaft war. Mit anderen Worten, der Datenstrom, den der Client an den Server gesendet hat, hat die Regeln nicht befolgt.

Im Fall eines REST-API mit einem JSON-Payload werden 400er Fehler typischerweise, und meiner Meinung nach richtig, verwendet, um anzuzeigen, dass das JSON auf irgendeine Weise gemäß der API-Spezifikation für den Dienst ungültig ist.

Nach dieser Logik sollten beide Szenarien also 400er Fehler sein.

Stellen Sie sich stattdessen vor, dass dies XML anstelle von JSON wäre. In beiden Fällen würde das XML niemals die Schema-Validierung bestehen - entweder aufgrund eines nicht definierten Elements oder eines falschen Elementwerts. Das wäre eine schlechte Anfrage. Das gleiche gilt hier.

Answer 2

Von w3.org

10.4.1 400 Bad Request

Die Anfrage konnte aufgrund fehlerhafter Syntax nicht vom Server verstanden werden. Der Client SOLLTE die Anfrage nicht wiederholen, ohne Änderungen vorzunehmen.

Answer 3

Die Auswahl eines HTTP-Antwortcodes ist eine ziemlich einfache Aufgabe und kann durch einfache Regeln beschrieben werden. Der einzige knifflige Teil, der oft vergessen wird, ist Absatz 6.5 von RFC 7231:

Außer bei einer Antwort auf eine HEAD-Anfrage sollte der Server eine Repräsentation senden, die eine Erklärung der Fehlersituation enthält und ob es sich um einen vorübergehenden oder dauerhaften Zustand handelt.

Die Regeln lauten wie folgt:

1. Wenn die Anfrage erfolgreich war, geben Sie den Code 2xx zurück (3xx für eine Weiterleitung). Wenn ein interner Logikfehler auf dem Server vorlag, geben Sie 5xx zurück. Wenn etwas mit der Clientanfrage nicht stimmt, geben Sie den Code 4xx zurück.
2. Schauen Sie sich die verfügbaren Antwortcodes aus der ausgewählten Kategorie an. Wenn einer von ihnen einen Namen hat, der gut zu Ihrer Situation passt, können Sie ihn verwenden. Andernfalls fallbacken Sie einfach auf den x00-Code (200, 400, 500). Wenn Sie Zweifel haben, fallbacken Sie auf den x00-Code.
3. Geben Sie eine Fehlerbeschreibung im Antwortkörper zurück. Bei 4xx-Codes muss es genügend Informationen enthalten, damit der Cliententwickler den Grund verstehen und den Client reparieren kann. Bei 5xx darf aus Sicherheitsgründen keine Details preisgegeben werden.
4. Wenn der Client unterschiedliche Fehler unterscheiden und je nach Fehler eine unterschiedliche Reaktion haben muss, definieren Sie ein maschinenlesbares und erweiterbares Fehlerformat und verwenden Sie es überall in Ihrer API. Es ist ratsam, dies von Anfang an zu tun.
5. Denken Sie daran, dass der Cliententwickler seltsame Dinge tun und versuchen kann, Zeichenfolgen zu analysieren, die Sie als menschenlesbare Beschreibung zurückgeben. Und wenn Sie die Zeichenfolgen ändern, brechen Sie solche schlecht geschriebenen Clients. Geben Sie also immer eine maschinenlesbare Beschreibung an und versuchen Sie, zusätzliche Informationen im Text zu vermeiden.

Also in Ihrem Fall würde ich einen 400-Fehler zurückgeben und etwas wie dies hier, wenn "Roman" von der Benutzereingabe stammt und der Client eine spezifische Reaktion haben muss:

{
    "error_type" : "unsupported_resource",
    "error_description" : "\"Roman\" wird nicht unterstützt"
}

oder einen allgemeineren Fehler, wenn eine solche Situation ein schlechter Logikfehler in einem Client ist und nicht erwartet wird, es sei denn, der Entwickler hat etwas falsch gemacht:

{
    "error_type" : "malformed_json",
    "error_description" : "\"Roman\" wird für das Feld \"requestedResource\" nicht unterstützt"
}

Answer 4

In keinem Fall ist die "Syntax fehlerhaft". Es sind die Semantik, die falsch sind. Daher ist meiner Meinung nach eine 400 unangemessen. Stattdessen wäre es angebracht, eine 200 zusammen mit einer Art Fehlerobjekt wie { "Fehler": { "Nachricht": "Unbekanntes Anfrage-Schlüsselwort" } } oder ähnliches zurückzugeben.

Betrachten Sie die Verarbeitungspfade des Clients. Ein Fehler in der Syntax (z.B. ungültiges JSON) ist ein Fehler in der Logik des Programms, anders gesagt ein Fehler irgendwelcher Art, und sollte entsprechend behandelt werden, ähnlich wie z.B. ein 403; mit anderen Worten, etwas Schlechtes ist passiert.

Ein Fehler im Wert eines Parameters hingegen ist ein semantischer Fehler, möglicherweise aufgrund eines schlecht validierten Benutzereingabe. Es ist kein HTTP-Fehler (obwohl es auch ein 422 sein könnte). Der Verarbeitungspfad wäre anders.

Zum Beispiel würde ich in jQuery lieber keinen einzigen Fehlerhandler schreiben müssen, der sowohl mit Dingen wie 500 als auch mit spezifischen semantischen Fehlern der App umgeht. Andere Frameworks, wie z.B. Ember, behandeln auch HTTP-Fehler wie 400er und 500er identisch als große fette Misserfolge, wodurch der Programmierer erkennen muss, was los ist und je nachdem, ob es sich um einen "echten" Fehler handelt oder nicht, verzweigen muss.

Answer 5

Die Verwendung von 400 Statuscodes für einen anderen Zweck als die Angabe, dass die Anfrage fehlerhaft ist, ist einfach falsch.

Wenn die Anforderungsnutzlast eine Byte-Sequenz enthält, die nicht als application/json (wenn der Server dieses Datenformat erwartet) analysiert werden kann, ist der entsprechende Statuscode 415:

Der Server lehnt die Bearbeitung der Anfrage ab, weil die Entität der Anfrage in einem Format vorliegt, das vom angeforderten Ressourcen für die angeforderte Methode nicht unterstützt wird.

Wenn die Anforderungsnutzlast syntaktisch korrekt, aber semantisch inkorrekt ist, kann der nicht standardmäßige 422 Antwortcode verwendet werden, oder der standardmäßige 403 Statuscode:

Der Server hat die Anfrage verstanden, lehnt jedoch deren Erfüllung ab. Eine Autorisierung wird nicht helfen und die Anfrage SOLL NICHT wiederholt werden.