Quel est le code d'état HTTP approprié pour une demande générale infructueuse (pas une erreur) ?

Question

Je suis en train de créer une API RESTful qui traitera un certain nombre d'interactions avec les utilisateurs, notamment le passage de commandes à l'aide de cartes de crédit enregistrées.

Dans le cas d'une commande réussie, je renvoie un 200 OK, et dans le cas où la demande de commande est mal formée ou invalide, je renvoie un 400 Bad Request. Mais que dois-je renvoyer s'il y a un problème pendant le traitement de la commande ?

1. Le client POSTE un ordre au serveur pour une ressource utilisateur. Si l'utilisateur n'existe pas, 404 Not Found est retourné.
2. Le format et les informations de la commande sont validés. Si elles ne sont pas valides, le système renvoie le message 400 Bad Request.
3. La commande est traitée. Si la commande est réussie, un 201 Created est renvoyé pour la commande. Si une erreur inattendue est rencontrée, une erreur de serveur 500 est renvoyée.

C'est la dernière étape qui pose problème : que dois-je renvoyer si la commande n'aboutit pas pour une autre raison ? Voici quelques scénarios possibles :

• Le produit est épuisé
• Limite maximale d'ordre de l'utilisateur atteinte
• Échec de la transaction par carte de crédit (fonds insuffisants, etc.)

Cela ne semble pas être approprié pour un 400 ou un 500. Je pourrais même le voir comme un 400 s'il n'y a pas de meilleur code - la demande n'était pas valide selon les règles de l'entreprise. Mais cela ne semble pas exact.

Edit : Aussi trouvé cette discussion existante du même sujet. Toutes les réponses semblent indiquer l'utilisation de codes d'état pour ce type de violation, avec une discussion entre l'utilisation de 400, 409 ou l'extension 422.

Answer 1

Vous devriez utiliser 400 pour les règles de gestion. Ne renvoyez pas 2xx si la commande n'a pas été acceptée. HTTP est un protocole d'application, ne l'oubliez jamais. Si vous renvoyez 2xx, le client peut supposer que la commande a été acceptée, quelles que soient les informations que vous envoyez dans le corps du message.

---

De Livre de cuisine sur les services Web RESTful :

Une erreur courante que font certains services web est de renvoyer un statut qui reflète le succès (codes d'état de 200 à 206 et de 300 à 307), mais d'inclure un corps de message qui décrit une condition d'erreur. à 307) mais en incluant un corps de message qui décrit une condition d'erreur. Cela empêche les logiciels sensibles au protocole HTTP de détecter les erreurs. Par exemple, Par exemple, un cache la stockera comme une réponse réussie et la servira aux clients suivants, même si les clients peuvent être en mesure d'accéder aux données. et la servira aux clients suivants, même si les clients sont en mesure d'effectuer une demande.

Je vous laisse le soin de choisir entre 4xx et 5xx, mais vous devriez utiliser un code d'état d'erreur.

Answer 2

Vous devriez utiliser 4xx pour une erreur client si le client peut modifier la requête pour contourner l'erreur. Utilisez un 5xx pour une erreur de serveur que le client ne peut pas vraiment contourner.

Un produit épuisé serait une erreur de serveur. Le client ne peut pas modifier la requête d'une manière ou d'une autre pour contourner l'erreur. Vous pourriez passer à un autre produit, mais ne s'agirait-il pas d'une nouvelle demande ?

La limite maximale de commande atteinte par l'utilisateur est également une erreur de serveur. Le client ne peut rien faire pour contourner cette erreur.

L'échec de la transaction par carte de crédit serait une erreur du client. Le client peut soumettre à nouveau la demande avec un autre mode de paiement ou un autre numéro de carte de crédit pour contourner l'erreur.

Answer 3

Type d'erreur :

4×× Client Error

Code d'erreur :

422 Unprocessable Entity

Le serveur comprend le type de contenu de l'entité de demande (le code d'état 415 Unsupported Media Type est donc inapproprié) et la syntaxe de l'entité de demande est correcte (le code d'état 400 Bad Request est donc inapproprié) mais n'a pas pu traiter les instructions contenues.

Par exemple, cette condition d'erreur peut se produire si un corps de demande XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

https://httpstatuses.com/422

Answer 4

Je sais que cette question est ancienne, mais je me suis posé la même question aujourd'hui. Si mon utilisateur n'a plus de crédits, quel code d'état mon API REST doit-elle renvoyer ?

J'ai tendance à pencher vers 402 Payment Required :

Según Wikipedia :

Réservé pour une utilisation future. L'intention initiale était que ce code soit utilisé dans le cadre d'une forme d'argent numérique ou de micropaiement, mais cela ne s'est pas produit, et ce code n'est généralement pas utilisé. L'API Google Developers utilise ce statut si un développeur particulier a dépassé la limite quotidienne de demandes.

Et en effet ils le font :

PAYMENT_REQUIRED (402)

• Une limite budgétaire quotidienne fixée par le développeur a été atteinte.
• L'opération demandée nécessite plus de ressources que le quota ne le permet. Un paiement est nécessaire pour effectuer l'opération.
• L'opération demandée nécessite une forme de paiement de la part de l'utilisateur authentifié.

Answer 5

Et si 424 Failed Dependency ? La fiche technique le décrit comme suit :

La méthode n'a pas pu être exécutée sur la ressource car l'action demandée dépendait d'une autre action et celle-ci a échoué.

Mais il y a aussi cette définition :

Le code d'état 424 est défini dans la norme WebDAV et correspond à un cas où le client doit changer ce qu'il fait - le serveur ne rencontre aucun problème ici.

Vous pouvez dire au client (ou prétendre) que vous avez des actions internes qui sont censées créer la commande et déduire le solde, et que l'une de ces actions a échoué, bien que pour des raisons parfaitement valables, et que c'est la raison pour laquelle la demande a échoué.

D'après ce que je peux voir, "action" est un terme assez large, qui peut être utilisé dans une variété de situations, y compris un stock insuffisant, un crédit insuffisant, ou une nuit de fête dans un entrepôt.

---

Une autre option pourrait être 422 Unprocessable Entity :

Le serveur comprend le type de contenu de l'entité de demande (le code d'état 415 Unsupported Media Type est donc inapproprié) et la syntaxe de l'entité de demande est correcte (le code d'état 400 Bad Request est donc inapproprié) mais n'a pas pu traiter les instructions contenues.

Par exemple, cette condition d'erreur peut se produire si un corps de demande XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

Essayer de demander un article qui n'est pas en stock, ou lorsque vous avez un crédit insuffisant, peut être considéré comme une erreur au niveau sémantique.

MozDev dit cela indique une erreur du côté client, spécifiquement : Le client ne doit pas répéter cette demande sans modification.

Boucleur 4 utilise 422 lorsque la validation des entrées échoue.

---

On peut soutenir qu'un stock insuffisant ou une nuit de fête à l'entrepôt pourraient être considérés comme des états temporaires, de sorte que la demande pourrait être relancée ultérieurement. Cette situation peut être indiquée par 503 Service Unavailable

Le serveur est actuellement incapable de traiter la demande en raison d'une surcharge temporaire ou d'une maintenance programmée, qui sera probablement allégée après un certain délai.

Le serveur peut envoyer un champ d'en-tête Retry-After pour suggérer au client un délai d'attente approprié avant de réessayer la demande.