147 votes

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

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.

2voto

Rajender Saini Points 334

Je ne pense pas que 400 puisse être utilisé pour tous les scénarios d'affaires. Il peut être utilisé pour la validation de base des entrées de données. Au-delà de cela, nous pourrions avoir du mal à intégrer une autre logique métier dans ce code d'erreur. Les erreurs traitées par ce code sont principalement des erreurs de conception que le développeur rencontrera éventuellement pendant le codage du client.

Disons que tous les paramètres sont corrects et que nous passons le numéro de compte utilisateur dans la requête.

La demande n'est donc plus une mauvaise demande, le serveur est en mesure d'accepter la demande. Mais il refuse maintenant de la traiter sur la base des nouvelles informations disponibles, à savoir que le compte n'a pas un solde suffisant.

Je pense que nous devrions utiliser 403 avec un message d'erreur approprié dans ces scénarios.

Un autre code d'erreur possible pourrait être le conflit 409. Mais il est utilisé dans des scénarios où la ressource est dans un état cohérent.

-1voto

Mahmoud Zalt Points 62

Je vais avec 406 Not Acceptable .

Voici une liste de 4xx :

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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X