Welchen HTTP-Statuscode sollte ich zurückgeben, wenn ein Client fehlerhafte Daten sendet (z. B. einen String, obwohl eine ganze Zahl erwartet wurde)?
Ich habe 400 Bad Request verwendet, aber wenn ich die HTTP-Dokumente durchlese, scheint das eher für HTTP-Protokollfehler zu gelten.
Ich möchte einen Statuscode verwenden, damit Flash- und AJAX-Clients zwischen Erfolg, fehlerhaften Daten und einem Serverfehler unterscheiden können, ohne eine Antwort parsen zu müssen.
Im Falle einer fehlerhaften Syntax verwenden Sie "400 Bad Request".
Die Anfrage konnte vom Server aufgrund einer fehlerhaften Syntax nicht verstanden werden. Der Client SOLLTE die Anfrage NICHT unverändert wiederholen.
Bei fehlerhaften Daten (und korrekter Syntax) verwenden Sie "422 Unprocessable Entity".
Der Statuscode 422 (Unprocessable Entity) bedeutet, dass der Server den Inhaltstyp der Anforderungseinheit versteht (daher ist ein Statuscode 415 (Unsupported Media Type) unangebracht) und die Syntax der Anforderungseinheit korrekt ist (daher ist ein Statuscode 400 (Bad Request) unangebracht), aber die enthaltenen Anweisungen nicht verarbeiten konnte. Diese Fehlerbedingung kann beispielsweise auftreten, wenn ein XML-Anfragekörper wohlgeformte (d. h. syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.
Ver https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm
Siehe auch https://softwareengineering.stackexchange.com/a/342896/158699 Antwort, mit korrektem 400er und 422er Code.
Ich würde eher dazu neigen, die fehlerhaften Daten im Browser abzufangen, wenn der Kunde auf die Schaltfläche "Submit" klickt.
Wenn nicht, dann würde ich 400 zurückgeben, denn wie die Norm sagt:
Die Anfrage konnte vom Server aufgrund einer fehlerhaften Syntax nicht verstanden werden. Der Client SOLLTE die Anfrage NICHT unverändert wiederholen.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
