400 BAD Anfrage HTTP Fehlercode Bedeutung?

Eine 400 bedeutet, dass die Anforderung fehlerhaft ist. Mit anderen Worten, der vom Client an den Server gesendete Datenstrom hat die Regeln nicht eingehalten.

Im Fall einer REST -API mit einer JSON-Nutzlast werden normalerweise und korrekterweise 400 verwendet, um anzuzeigen, dass die JSON gemäß der API-Spezifikation für den Service in irgendeiner Weise ungültig ist.

Nach dieser Logik sollten beide von Ihnen bereitgestellten Szenarien 400 sein.

Stellen Sie sich stattdessen vor, dies wäre XML und nicht JSON. In beiden Fällen würde das XML die Schemaüberprüfung niemals bestehen - entweder aufgrund eines undefinierten Elements oder eines falschen Elementwerts. Das wäre eine schlechte Anfrage. Gleiche Sache hier.

Von w3.org

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.

Die Auswahl eines HTTP-Antwortcodes ist recht einfach und kann durch einfache Regeln beschrieben werden. Der einzige schwierige Teil, der oft vergessen wird, ist Absatz 6.5 aus RFC 7231:

Außer wenn auf eine HEAD -Anforderung geantwortet wird, MUSS der Server eine Darstellung senden, die eine Erläuterung der Fehlersituation enthält und angibt, ob es sich um einen vorübergehenden oder dauerhaften Zustand handelt.

Die Regeln lauten wie folgt:

1. Wenn die Anforderung erfolgreich war, geben Sie den Code 2xx zurück (3xx für die Umleitung). Wenn auf einem Server ein interner Logikfehler aufgetreten ist, geben Sie 5xx zurück. Wenn die Clientanforderung fehlerhaft ist, geben Sie den 4xx-Code zurück.
2. Durchsuchen Sie den verfügbaren Antwortcode der ausgewählten Kategorie. Wenn einer von ihnen einen Namen hat, der gut zu Ihrer Situation passt, können Sie ihn verwenden. Ansonsten einfach auf x00-Code zurückgreifen (200, 400, 500). Im Zweifelsfall auf x00-Code zurückgreifen.
3. Gibt eine Fehlerbeschreibung im Antworttext zurück. Für 4xx-Codes muss es genügend Informationen enthalten, damit der Client-Entwickler den Grund versteht und den Client repariert. Für 5xx müssen aus Sicherheitsgründen keine Angaben gemacht werden.
4. Wenn der Client unterschiedliche Fehler unterscheiden und abhängig davon unterschiedliche Reaktionen ausführen muss, definieren Sie ein maschinenlesbares und erweiterbares Fehlerformat und verwenden Sie es überall in Ihrer API. Es ist eine gute Praxis, das von Anfang an zu machen.
5. Denken Sie daran, dass Client-Entwickler möglicherweise seltsame Dinge tun und versuchen, Zeichenfolgen zu analysieren, die Sie als vom Menschen lesbare Beschreibung zurückgeben. Und wenn Sie die Zeichenfolgen ändern, werden Sie solche schlecht geschriebenen Clients kaputt machen. Geben Sie daher immer eine maschinenlesbare Beschreibung an und vermeiden Sie es, zusätzliche Informationen im Text anzugeben.

In Ihrem Fall habe ich also 400 Fehler und so etwas zurückgegeben, wenn "Roman" aus Benutzereingaben erhalten wird und der Client eine bestimmte Reaktion haben muss:

{
    "error_type" : "unsupported_resource",
    "error_description" : "\"Roman\" is not supported"
}

oder ein allgemeinerer Fehler, wenn eine solche Situation ein fehlerhafter 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\" is not supported for \"requestedResource\" field"
}

In keinem Fall ist die "Syntax fehlerhaft". Es ist die Semantik, die falsch ist. Daher ist meiner Meinung nach eine 400 unangemessen. Stattdessen wäre es angebracht, eine 200 zusammen mit einer Art Fehlerobjekt wie { "error": { "message": "Unknown request keyword" } } oder was auch immer zurückzugeben.

Berücksichtigen Sie die Clientverarbeitungspfade. Ein Fehler in der Syntax (z. B. ungültiges JSON) ist ein Fehler in der Logik des Programms, mit anderen Worten, ein Fehler in irgendeiner Form, und sollte dementsprechend behandelt werden, etwa ähnlich wie bei 403; Mit anderen Worten, etwas Schlimmes ist schiefgegangen.

Ein Fehler in einem Parameterwert ist andererseits ein semantischer Fehler, möglicherweise aufgrund einer schlecht validierten Benutzereingabe. Es ist kein HTTP-Fehler (obwohl es sich vermutlich um einen 422er handeln könnte). Der Verarbeitungspfad wäre anders.

In jQuery würde ich es beispielsweise vorziehen, keinen einzigen Fehlerbehandler zu schreiben, der sich mit beiden Dingen wie 500 und einigen app-spezifischen semantischen Fehlern befasst. Andere Frameworks, zum Beispiel Ember, behandeln HTTP-Fehler wie 400er und 500er ebenfalls als große Fehler, sodass der Programmierer erkennen und verzweigen muss, je nachdem, ob es sich um einen "echten" Fehler handelt oder nicht.

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

Wenn die Anforderungsnutzdaten eine Byte-Sequenz enthalten, die nicht als application/json analysiert werden konnte (wenn der Server dieses Datenformat erwartet), lautet der entsprechende Statuscode 415:

Der Server weigert sich, die Anforderung zu bearbeiten, da die Entität der Anforderung in einem Format vorliegt, das von der angeforderten Ressource für die angeforderte Methode nicht unterstützt wird.

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

Der Server hat die Anfrage verstanden, lehnt sie jedoch ab. Die Autorisierung hilft nicht und die Anfrage SOLLTE NICHT wiederholt werden.

Denken Sie über Erwartungen nach.

Als Client-App müssen Sie wissen, ob auf der Serverseite etwas schief geht. Wenn der Server einen Fehler auslösen muss, wenn blah fehlt oder der Wert requestedResource falsch ist, ist ein 400-Fehler angemessen.

Überprüfen Sie zuerst die URL, die möglicherweise falsch ist. Wenn sie korrekt ist, überprüfen Sie den von Ihnen gesendeten Anfragetext. Möglicherweise fehlt die richtige Syntax für die gesendete Anfrage.

Überprüfen Sie zum Ausarbeiten die Anforderungszeichenfolge auf Sonderzeichen. Wenn es (Sonderzeichen) verwendet wird, ist dies die Hauptursache für diesen Fehler.

kopieren Sie die Anforderung und analysieren Sie alle Tag-Daten.

Ergänzend dazu verwende ich $.ajax, um Formulardaten auf dem Server zu veröffentlichen, und es wird zuerst der Fehler 400 angezeigt.

Angenommen, ich habe eine Javascript-Variable,

            var formData = {
                "name":"Gearon",
                "hobby":"Be different"
                }; 

Verwenden Sie die Variable formData nicht direkt als Wert des Schlüssels data wie folgt:

            $.ajax({
                type: "post",
                dataType: "json",
                url: "http://localhost/user/add",
                contentType: "application/json",
                data: formData,
                success: function(data, textStatus){
                    alert("Data: " + data + "\nStatus: " + status); 
                }
            });

Verwenden Sie stattdessen JSON.stringify, um das formData wie folgt zu kapseln:

            $.ajax({
                type: "post",
                dataType: "json",
                url: "http://localhost/user/add",
                contentType: "application/json",
                data: JSON.stringify(formData),
                success: function(data, textStatus){
                    alert("Data: " + data + "\nStatus: " + status); 
                }
            });

Wie andere bereits gezeigt haben, liegt der Fehler daran, dass der Server die Anfrage aufgrund einer fehlerhaften Syntax nicht erkennen konnte. In der Praxis wird nur eine Instanz ausgelöst. Hoffe es wäre jemandem behilflich.