Code d'état HTTP pour une demande partiellement réussie

Question

J'ai une application qui envoie des messages aux utilisateurs. Dans une demande d'envoi, une chaîne XML est transférée, contenant tous les utilisateurs qui doivent recevoir ce message particulier. Si l'un des utilisateurs de la liste n'existe pas, je renvoie la liste des utilisateurs manquants au client pour une évaluation ultérieure.

Je me demande maintenant quel serait le code d'état approprié pour l'application indiquant que la demande a été acceptée mais que certaines choses n'ont pas pu être faites.

Le problème serait évité s'il n'était pas permis d'inclure les utilisateurs manquants dans la liste. Dans ce cas, la tentative d'envoi recevrait simplement une erreur 4xx. Mais il n'y a aucun intérêt à former l'API de cette façon. D'un autre côté, je pourrais considérer que la condition d'erreur est purement spécifique à l'application. Mais l'envoi d'un 200 ne semble pas correct. Et ce serait bien de donner au client un indice lui permettant d'examiner en profondeur la réponse d'erreur, par exemple pour éviter d'envoyer des messages à cet utilisateur à plusieurs reprises.

Answer 1

J'ai eu affaire à un problème très similaire. Dans ce cas, j'ai renvoyé un

207 Multi-status

Il ne s'agit pas de HTTP strict, mais d'une partie de l'extension WebDAV, donc si vous n'avez pas le contrôle du client, ce n'est pas bon pour vous. Si vous le faites, vous pouvez faire quelque chose comme ça :

   <?xml version="1.0" encoding="utf-8" ?>
   <D:multistatus xmlns:D='DAV:'>
     <D:response>
       <D:user>user-123</D:user>
       <D:status>success</D:status>
     </D:response>
     <D:response>
       <D:user>user-789</D:user>
       <D:status>failure</D:status>
     </D:response>
   </D:multistatus>

Mais là encore, il s'agit d'une extension HTTP, et vous devez également contrôler le client.

Answer 2

J'ai eu le même problème, et j'ai fini par utiliser deux solutions différentes :

• Code de retour HTTP 202: Accepted indiquant que la demande a été acceptée, mais qu'il n'y a aucune garantie que tout se soit passé comme prévu.
• Retour d'une normale 200 dans la réponse, mais inclure une liste de ce qui n'a pas marché dans le corps de la réponse.

La deuxième solution est généralement la plus efficace, mais la première est idéale si vous êtes paresseux ou si vous utilisez une file d'attente pour le traitement.

Answer 3

Pourquoi ne pas utiliser le contenu partiel 206 ? Je sais que 206 concerne plutôt les plages, mais si cela pouvait indiquer une requête partiellement réussie ?

Answer 4

Le protocole de transfert hypertexte (HyperText Transfer Protocol) traite de l'aspect transmission. Il ne dispose pas de codes d'erreur pour traiter les erreurs au niveau des applications.

Renvoyer 200 est la bonne chose à faire ici. En ce qui concerne le protocole HTTP, la demande a été reçue correctement, traitée correctement et vous renvoyez la réponse. Donc, au niveau du protocole HTTP, tout est OK. Toute erreur ou tout avertissement lié à l'application qui s'exécute au-dessus de HTTP doit figurer dans la réponse. Cela permet également d'éviter les problèmes que vous pourriez rencontrer avec les serveurs proxy qui ne traitent pas certaines réponses comme vous le souhaitez.