Quelle est la réponse appropriée du code d'état HTTP pour une demande générale infructueuse (pas une erreur)?
Je crée une API RESTful qui traitera un certain nombre d'interactions avec les utilisateurs, y compris passer des commandes à l'aide de cartes de crédit stockées.
Dans le cas d'une commande réussie, je retourne un 200 OK, et dans le cas où la demande de commande est incorrecte ou invalide, je retourne une 400 mauvaise demande. Mais que dois-je retourner en cas de problème lors du traitement de la commande?
- Le client envoie une commande au serveur pour une ressource utilisateur. Si l'utilisateur n'existe pas, 404 Not Found est renvoyé.
- Le format de commande et les informations sont validés. S'il n'est pas valide, 400 Bad Request est retourné.
- La commande est traitée. Si la commande est réussie, un 201 créé est retourné pour la commande. Si une erreur inattendue se produit, une erreur de serveur 500 est renvoyée.
La dernière étape est le problème - que dois-je retourner si la commande ne se termine pas pour une autre raison? Les scénarios possibles pourraient inclure:
- Le produit est épuisé
- Limite maximale de commande 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. Si je pouvais le voir comme un 400 s'il n'y a pas de meilleur code - la demande n'était pas valide selon les règles commerciales. Cela ne semble tout simplement pas exact.
Edit: également 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.
Vous devez utiliser 4xx pour une erreur client si le client peut modifier la demande pour contourner l'erreur. Utilisez un 5xx pour une erreur de serveur que le client ne peut pas vraiment contourner.
Le produit épuisé serait une erreur de serveur. Le client ne peut pas modifier la demande 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 de commande maximale 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.
Type d'erreur:
4×× Client Error
Code d'erreur:
422 Unprocessable Entity
Le serveur comprend le type de contenu de l'entité de demande (par conséquent, un code d'état 415 Unsupported Media Type est inapproprié) et la syntaxe de l'entité de demande est correcte (donc un code d'état 400 Bad Request est inapproprié) mais n'a pas pu traiter le contenu instructions.
Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes) mais sémantiquement erronées.
Je sais que cette question est ancienne, mais j'ai posé la même question aujourd'hui. Si mon utilisateur manque de crédits, quel code de statut mon API REST doit-elle renvoyer?
J'ai tendance à me pencher vers 402 Payment Required:
Selon Wikipedia :
Réservé pour une utilisation future. L'intention initiale était que ce code puisse être utilisé dans le cadre d'une certaine forme de système de paiement 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. Le paiement est requis pour terminer l'opération.
- L'opération demandée nécessite une sorte de paiement de la part de l'utilisateur authentifié.
Que diriez-vous 424 Failed Dependency ? La spécification le décrit comme:
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 cette action a échoué.
Mais il y a aussi cette définition :
Le code d'état 424 est défini dans la norme WebDAV et est destiné au cas où le client doit modifier ce qu'il fait - le serveur ne rencontre aucun problème ici.
Vous pouvez dire au client (ou faire semblant) 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 c'est pourquoi la demande a échoué.
Pour autant que je puisse voir, "action" est un terme assez large et peut être utilisé dans diverses situations, notamment un stock insuffisant, un crédit insuffisant ou une soirée entrepôt.
Une autre option pourrait être 422 Unprocessable Entity :
Le serveur comprend le type de contenu de l'entité de demande (donc un code d'état 415 Unsupported Media Type est inapproprié) et la syntaxe de l'entité de demande est correcte (donc un code d'état 400 Bad Request est inapproprié) mais n'a pas pu traiter le contenu instructions.
Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes) mais sémantiquement erronées.
Essayer de demander un article en rupture de stock ou lorsque votre crédit est insuffisant peut être considéré comme une erreur au niveau sémantique.
On peut penser que le stock insuffisant ou la nuit de fête d'entrepôt pourraient être considérés comme des états temporaires, de sorte que la demande pourrait être réessayée plus tard. Cette situation peut être indiquée par 503 Service Unavailable
Le serveur n'est actuellement pas en mesure de traiter la demande en raison d'une surcharge temporaire ou d'une maintenance planifiée, qui sera probablement atténuée après un certain retard.
Le serveur PEUT envoyer un champ d'en-tête Réessayer après pour suggérer une durée appropriée au client pour attendre avant de réessayer la demande.
Je ne pense pas que 400 puisse être utilisé pour tous les scénarios d'entreprise. Il peut être utilisé pour la validation de base de la saisie 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 sont principalement des erreurs de conception que le développeur rencontrera éventuellement lors du codage du client.
Supposons que tous les paramètres soient corrects et supposons que nous transmettons le numéro de compte d'utilisateur à la demande.
Donc, la demande n'est plus une mauvaise demande, le serveur peut accepter la demande. Mais maintenant, il refuse de remplir la demande sur la base des nouvelles informations disponibles, c'est-à-dire que le compte n'a pas un solde suffisant.
Je suggère que nous devrions utiliser 403 avec un message d'erreur approprié dans ces scénarios.
Un autre code d'erreur possible pourrait être un conflit 409. Mais cela est utilisé dans des scénarios où la ressource est dans un état cohérent.
Je vais avec 406 Not Acceptable.
Voici une liste 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