it-swarm.com.de

Richtiger HTTP-Statuscode zu falscher Eingabe

Was ist der optimale HTTP-Antwortcode, wenn nicht 200 gemeldet werden (alles in Ordnung), sondern ein Eingabefehler vorliegt?

Sie übermitteln einige Daten an den Server und es wird darauf reagiert, dass Ihre Daten falsch sind

mit 500 ähnelt eher einem Serverproblem
mit 200 mit Warn-/Fehlerantworttext ist fehlerhaft (Caching zulassen und alles ist nicht in Ordnung)
mit 204 und nichts zurückgeben, ist vielleicht gut (aber gut unterstützt?)
mit 404 ist falsch, wenn der angeforderte Pfad (Skript) verfügbar ist und sich an der richtigen Stelle befindet

140
Marek Sebera

Wir hatten das gleiche Problem bei der Erstellung unserer API. Wir haben nach einem HTTP-Statuscode gesucht, der einem InvalidArgumentException entspricht. Nachdem wir den folgenden Quellartikel gelesen hatten, verwendeten wir schließlich 422 Unprocessable Entity welche Staaten:

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.

quelle: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

162
Keego

Codes, die mit 4 (4xx) beginnen, sind für Clientfehler gedacht. Vielleicht könnten 400 (Bad Request) für diesen Fall geeignet sein? Definition in http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html sagt:

"Die Anfrage konnte vom Server aufgrund einer fehlerhaften Syntax nicht verstanden werden. Der Client SOLLTE die Anfrage NICHT ohne Änderungen wiederholen."

132
esaj

Zusätzlich zu RFC Spec können Sie dies auch in Aktion sehen. Sehen Sie sich die Antworten auf Twitter und Facebook an.

https://developer.Twitter.com/en/docs/ads/general/guides/response-codes

http://www.fb-developers.info/tech/fb_dev/faq/general/gen_10.html

13
Mob

409 Conflict könnte eine akzeptable Lösung sein.

Laut: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Die Anforderung konnte aufgrund eines Konflikts mit dem aktuellen Status der Ressource nicht abgeschlossen werden. Dieser Code ist nur in Situationen zulässig, in denen erwartet wird, dass der Benutzer den Konflikt möglicherweise lösen und die Anforderung erneut senden kann. Der Antworttext SOLLTE genügend Informationen enthalten, damit der Benutzer die Ursache des Konflikts erkennen kann. Im Idealfall würde die Antwortentität genügend Informationen enthalten, damit der Benutzer oder Benutzeragent das Problem beheben kann. Dies ist jedoch möglicherweise nicht möglich und nicht erforderlich.

Das Dokument fährt mit einem Beispiel fort:

Konflikte treten am wahrscheinlichsten als Reaktion auf eine PUT-Anforderung auf. Wenn beispielsweise die Versionierung verwendet wird und die Entität, die PUT ist, Änderungen an einer Ressource enthält, die mit den von einer früheren (Drittanbieter-) Anforderung vorgenommenen Konflikten in Konflikt stehen, verwendet der Server möglicherweise die Antwort 409, um anzuzeigen, dass die Anforderung nicht abgeschlossen werden kann . In diesem Fall enthält die Antwortentität wahrscheinlich eine Liste der Unterschiede zwischen den beiden Versionen in einem Format, das durch den Inhaltstyp der Antwort definiert wird.


In meinem Fall möchte ich einen String, der eindeutig sein muss, über eine API in eine Datenbank einfügen. Bevor ich es zur Datenbank hinzufüge, überprüfe ich, ob es noch nicht in der Datenbank vorhanden ist.

Wenn es so ist, werde ich zurückkehren "Error: The string is already in the database", 409.

Ich glaube, das ist, was das OP wollte: ein Fehlercode, der geeignet ist, wenn die Daten die Kriterien des Servers nicht erfüllen.

6