it-swarm.com.de

Was ist die geeignete HTTP-Statuscode-Antwort für eine allgemeine nicht erfolgreiche Anforderung (kein Fehler)?

Ich erstelle eine RESTful-API, die eine Reihe von Benutzerinteraktionen verarbeitet, einschließlich der Bestellung mit gespeicherten Kreditkarten.

Im Falle einer erfolgreichen Bestellung sende ich 200 OK zurück, und im Falle einer fehlerhaften oder ungültigen Bestellanforderung sende ich 400 Bad Request zurück. Was soll ich aber zurücksenden, wenn bei der eigentlichen Abwicklung der Bestellung ein Problem auftritt?

  1. Client POSTS-Auftrag an Server für eine Benutzerressource. Wenn der Benutzer nicht existiert, wird 404 Not Found zurückgegeben.
  2. Bestellformat und Informationen werden validiert. Wenn nicht gültig, wird 400 Bad Request zurückgegeben.
  3. Bestellung wird bearbeitet. Wenn die Bestellung erfolgreich ist, wird ein 201 Created für die Bestellung zurückgegeben. Wenn ein unerwarteter Fehler auftritt, wird ein 500-Server-Fehler zurückgegeben.

Der letzte Schritt ist das Problem - was kann ich zurücksenden, wenn die Bestellung aus einem anderen Grund nicht abgeschlossen wird? Mögliche Szenarien könnten sein:

  • Produkt ist ausverkauft
  • Maximales Bestelllimit des Benutzers erreicht
  • Kreditkarten-Transaktionsfehler (unzureichendes Guthaben usw.)

Dies scheint weder für eine 400 noch für eine 500 angemessen zu sein. Wenn überhaupt, könnte ich es als 400 ansehen, wenn es keinen besseren Code gibt - die Anfrage war gemäß den Geschäftsregeln ungültig. Es scheint einfach nicht genau zu sein.

Bearbeiten: Auch gefunden diese vorhandene Diskussion des gleichen Themas. Alle Antworten scheinen darauf hinzudeuten, Statuscodes für diese Art von Verstoß zu verwenden, wobei einige Diskussionen zwischen der Verwendung von 400, 409 oder der Erweiterung 422 geführt haben.

92
Raelshark

Sie sollten 4xx für einen Clientfehler verwenden, wenn der Client die Anforderung ändern kann, um den Fehler zu umgehen. Verwenden Sie 5xx für einen Serverfehler, den der Client nicht wirklich umgehen kann.

Produkt ausverkauft wäre ein Serverfehler. Der Client kann die Anforderung nicht in irgendeiner Weise ändern, um den Fehler zu umgehen. Sie könnten zu einem anderen Produkt wechseln, aber wäre das nicht eine neue Anfrage?

Das maximale Bestelllimit des Benutzers ist ebenfalls ein Serverfehler. Der Client kann diesen Fehler nicht umgehen.

Ein Fehler bei der Kreditkartentransaktion wäre ein Clientfehler. Der Client kann die Anforderung mit einer anderen Zahlungsmethode oder Kreditkartennummer erneut senden, um den Fehler zu umgehen.

21
Paul Morgan

Fehlertyp:

4×× Client Error

Fehlercode:

422 Unprocessable Entity

Der Server kennt den Inhaltstyp der Anforderungsentität (daher ist ein 415 Nicht unterstützter Medientyp-Statuscode ungeeignet), und die Syntax der Anforderungsentität ist korrekt (daher ist ein 400-Fehler-Anforderungsstatuscode ungeeignet), konnte jedoch den enthaltenen nicht verarbeiten Anleitung.

Diese Fehlerbedingung kann beispielsweise auftreten, wenn ein XML-Anforderungstext wohlgeformte (d. H. Syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

https://httpstatuses.com/422

19
stamster

Ich weiß, dass diese Frage alt ist, aber ich bin heute auf dieselbe Frage gekommen. Wenn meinem Benutzer die Credits ausgehen, welchen Statuscode sollte meine REST API zurückgeben?

Ich neige dazu, mich zu neigen zu 402 Payment Required:

Laut Wikipedia :

Reserviert für zukünftige Verwendung. Die ursprüngliche Absicht war, dass dieser Code als Teil eines digitalen Bargeld- oder Mikrozahlungsschemas verwendet wird, aber das ist nicht geschehen, und dieser Code wird normalerweise nicht verwendet. Die Google Developers API verwendet diesen Status, wenn ein bestimmter Entwickler das tägliche Anforderungslimit überschritten hat.

Und in der Tat sie tun :

BEZAHLUNG_ERFORDERLICH (402)

  • Ein vom Entwickler festgelegtes Tagesbudgetlimit wurde erreicht.
  • Die angeforderte Operation erfordert mehr Ressourcen, als das Kontingent zulässt. Die Zahlung ist erforderlich, um den Vorgang abzuschließen.
  • Für den angeforderten Vorgang muss der authentifizierte Benutzer eine Zahlung leisten.
10
Benjamin

Wie wäre es mit 424 Failed Dependency ? Die Spezifikation beschreibt es als:

Die Methode konnte für die Ressource nicht ausgeführt werden, da die angeforderte Aktion von einer anderen Aktion abhing und diese Aktion fehlschlug.

Es gibt aber auch diese Definition :

Der Statuscode 424 ist im WebDAV-Standard definiert und ist für den Fall vorgesehen, dass der Client Änderungen vornehmen muss - der Server hat hier keine Probleme.

Sie können dem Kunden mitteilen (oder vorgeben), dass Sie interne Aktionen haben, mit denen der Auftrag erstellt und der Saldo abgezogen werden soll, und dass eine dieser Aktionen fehlgeschlagen ist, wenn auch aus einwandfreien Gründen. Aus diesem Grund ist die Anforderung fehlgeschlagen.

Soweit ich sehen kann, ist "Aktion" ein ziemlich weit gefasster Begriff und kann in einer Vielzahl von Situationen verwendet werden, einschließlich unzureichender Lagerbestände, unzureichender Kredite oder Lagerpartynacht.


Eine andere Option könnte sein 422 Unprocessable Entity :

Der Server kennt den Inhaltstyp der Anforderungsentität (daher ist ein 415 Nicht unterstützter Medientyp-Statuscode ungeeignet), und die Syntax der Anforderungsentität ist korrekt (daher ist ein 400-Fehler-Anforderungsstatuscode ungeeignet), konnte jedoch den enthaltenen nicht verarbeiten Anleitung.

Diese Fehlerbedingung kann beispielsweise auftreten, wenn ein XML-Anforderungstext wohlgeformte (d. H. Syntaktisch korrekte), aber semantisch fehlerhafte XML-Anweisungen enthält.

Der Versuch, einen Artikel anzufordern, der nicht vorrätig ist, oder wenn Sie nicht genügend Guthaben haben, kann auf semantischer Ebene als Fehler angesehen werden.


Eine möglicherweise unzureichende Lager- oder Lagerpartynacht kann als vorübergehender Zustand angesehen werden, sodass die Anforderung später erneut versucht werden kann. Diese Situation kann durch 503 Service Unavailable

Der Server kann die Anforderung derzeit aufgrund einer vorübergehenden Überlastung oder geplanten Wartung nicht verarbeiten. Dies wird wahrscheinlich nach einer gewissen Verzögerung behoben.

Der Server KANN ein Retry-After-Headerfeld senden, um dem Client eine angemessene Wartezeit vorzuschlagen, bevor er die Anforderung erneut versucht.

3
joeytwiddle

Ich glaube nicht, dass 400 für das gesamte Geschäftsszenario verwendet werden kann. Es kann für die Validierung der Grunddateneingabe verwendet werden. Darüber hinaus ist es möglicherweise schwierig, andere Geschäftslogik in diesen Fehlercode einzufügen. Die Fehler, die hierdurch behandelt werden, sind meistens Entwurfszeitfehler, auf die Entwickler möglicherweise während des Codierens des Clients stoßen.

Angenommen, alle Parameter sind korrekt, und wir übergeben die Benutzerkontonummer an die Anforderung.

Damit die Anfrage nicht länger eine schlechte Anfrage ist, kann der Server die Anfrage annehmen. Jetzt weigert sie sich jedoch, die Anfrage auf der Grundlage neuer verfügbarer Informationen zu bearbeiten, da das Konto nicht über ausreichend Guthaben verfügt.

Ich würde vorschlagen, dass wir 403 mit entsprechender Fehlermeldung in diesen Szenarien verwenden sollten.

Ein anderer möglicher Fehlercode könnte der Konflikt 409 sein. Dies wird jedoch in Szenarien verwendet, in denen sich die Ressource im konsistenten Zustand befindet.

2
Rajender Saini

Ich gehe mit 406 Not Acceptable.

Hier ist eine 4xx-Liste:

const HTTP_BAD_REQUEST = 400;
const HTTP_UNAUTHORIZED = 401;
const HTTP_PAYMENT_REQUIRED = 402;
const HTTP_FORBIDDEN = 403;
const HTTP_NOT_FOUND = 404;
const HTTP_METHOD_NOT_ALLOWED = 405;
const HTTP_NOT_ACCEPTABLE = 406;
const HTTP_PROXY_AUTHENTICATION_REQUIRED = 407;
const HTTP_REQUEST_TIMEOUT = 408;
const HTTP_CONFLICT = 409;
const HTTP_GONE = 410;
const HTTP_LENGTH_REQUIRED = 411;
const HTTP_PRECONDITION_FAILED = 412;
const HTTP_REQUEST_ENTITY_TOO_LARGE = 413;
const HTTP_REQUEST_URI_TOO_LONG = 414;
const HTTP_UNSUPPORTED_MEDIA_TYPE = 415;
const HTTP_REQUESTED_RANGE_NOT_SATISFIABLE = 416;
const HTTP_EXPECTATION_FAILED = 417;
const HTTP_I_AM_A_TEAPOT = 418;                                               // RFC2324
const HTTP_MISDIRECTED_REQUEST = 421;                                         // RFC7540
const HTTP_UNPROCESSABLE_ENTITY = 422;                                        // RFC4918
const HTTP_LOCKED = 423;                                                      // RFC4918
const HTTP_FAILED_DEPENDENCY = 424;                                           // RFC4918
const HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL = 425;   // RFC2817
const HTTP_UPGRADE_REQUIRED = 426;                                            // RFC2817
const HTTP_PRECONDITION_REQUIRED = 428;                                       // RFC6585
const HTTP_TOO_MANY_REQUESTS = 429;                                           // RFC6585
0
Mahmoud Zalt