Quel code Http dois-je renvoyer pour "Thing not found" ?

Question

Je suis en train de construire un service web qui est utilisé, dans ce cas particulier, pour demander des informations sur un client.

Disons, pour les besoins de l'argumentation, que le résultat de la recherche sur le web est :

GET /patrons/619 HTTP/1.1

Si le client est trouvé, je renvoie le code 200 :

HTTP/1.1 200 OK

Si vous omettez, ou si vous donnez un numéro de compte qui n'est pas un numéro, je renvoie 400. Par exemple, les mauvaises demandes suivantes :

GET /patrons HTTP/1.1
GET /patrons/ HTTP/1.1
GET /patrons/qwerty HTTP/1.1
GET /patrons/kylie%20guenin HTTP/1.1

tous renvoient l'erreur 400 (Bad Request), par exemple :

HTTP/1.1 400 Invalid patron number

---

Je veux avoir un code d'état pour Patron non trouvé retourné comme code d'état HTTP. Par exemple :

GET /patrons/1322 HTTP/1.1

HTTP/1.1 404 Not Found

J'ai pensé à utiliser 404 (non trouvé) qui es une réponse valide (la ressource demandée n'a, vraiment, pas été trouvée). Mais j'ai peur que les personnes qui déboguent le système pensent que cela signifie qu'ils ont épelé /patrons/ mauvais.

Quelqu'un peut-il penser à un autre code de statut http que je pourrais utiliser ?

---

Mise à jour : je regarde

204 No Content 
The server successfully processed the request, but is not returning any content. 

Qu'en dites-vous ?

---

N'oubliez pas que tous les serveurs HTTP ne fournissent pas du contenu HTML. Si un serveur web IIS est sollicité pour une ressource appelée :

GET /MyStartPage.html HTTP/1.1

Ensuite, le serveur HTTP doit décider de la réponse à donner. Sur la plupart des serveurs web, une ressource nommée /MaPageDebut.html correspond à un fichier se trouvant sur le disque dur.

Alors que StackOverflow le fait :

GET /posts/1027301 HTTP/1.1

Et si cette ressource n'existe pas, le serveur web devrait (à juste titre) renvoyer 404.

Answer 1

Cela dépend du type de service Web que vous construisez.

Les webservices SOAP et XML renvoient généralement 200 OK si l'objet demandé (patron) est introuvable et codent le type d'erreur/message/description dans le document de réponse. Ils séparent un niveau de transport (HTTP) des messages échangés (XML). Une erreur 404 (qui se situe au niveau du transport) est renvoyée uniquement si vous demandez un point de terminaison API inexistant (mauvaise URL).

Avec un webservice REST cependant, vous utilisez directement les méthodes et statuts HTTP pour l'échange de messages. REST utilise différentes méthodes HTTP (GET/POST/PUT/DELETE) pour spécifier l'action souhaitée et le serveur renvoie le statut en tant que statut HTTP. Ainsi, dans le cas d'un webservice REST, 404 serait le statut HTTP approprié si un client ne peut être trouvé.

500 est inapproprié dans tous les cas je pense, puisque 5xx signifie qu'il y a eu un problème du côté serveur (ce qui n'est pas le cas) alors que les erreurs 4xx signifient qu'il y a un problème du côté client.

Answer 2

Il a peut-être 4 ans, mais il est toujours d'actualité. Pour les API qui doivent être utilisées à la fois par les développeurs et les applications natives, je trouve qu'il est beaucoup plus simple d'utiliser les codes HTTP pour l'indication du statut. Et si nécessaire, utiliser quelques codes supplémentaires parmi ceux qui ne sont pas attribués pour les conditions qui ne correspondent pas aux codes HTTP existants.

Answer 3

Les erreurs au niveau du service web ne doivent pas se contenter de renvoyer une simple ligne d'état HTTP, mais doivent plutôt renvoyer un contenu dans un format valide et documenté qui peut être analysé par le client accédant à votre service. Le document renvoyé doit contenir un code d'erreur faisant partie d'un ensemble documenté de codes spécifiques à votre service web, ainsi qu'une brève description du problème et, éventuellement, une description plus détaillée du problème.

Answer 4

Si vous voulez contrôler les réponses du service web par le biais des codes de réponse HTTP, vous pouvez effectivement utiliser un 404 pour indiquer cette condition.

Cependant, je pense qu'il est plus naturel de définir la réponse du service web entièrement dans le corps de la réponse HTTP, et de retourner simplement 200 pour une communication réussie ("J'ai compris votre demande et je vous ai envoyé une réponse appropriée"). Dans ce cas, vous renverriez 200 comme d'habitude, avec les données utiles de votre requête (XML ou JSON ou autre) indiquant qu'aucune entité correspondante n'a été trouvée.

Je considérerais les codes d'erreur non-200 comme des exceptions dans les langages de programmation conventionnels, et le corps de la réponse HTTP comme un code de retour. Imaginez que vous mettiez en œuvre cette méthode de manière conventionnelle : lanceriez-vous une exception si aucune entité n'était trouvée, ou renverriez-vous le code de retour null ? Personnellement, étant donné la nature fragile des connexions réseau, je voudrais réserver tous les codes d'erreur de niveau HTTP aux problèmes de communication, et je préférerais toujours renvoyer l'information suivante 200 OK du service lui-même, ainsi qu'une charge utile spécifiant le résultat ou toute erreur au niveau du service.