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

Si c'est un service, il n'est pas vraiment utilisé par des humains mais par des machines, et les fautes de frappe ne devraient donc pas être votre première préoccupation.

De plus, il y a très peu de choses que vous pourrez faire pour contrer le comportement humain (penser une chose alors qu'il s'agit en réalité d'une autre). Si vous renvoyez un petit message d'erreur dans le cadre du code d'erreur, tout devrait s'arranger. Vous pouvez même leur suggérer une solution possible.

Renvoyer un 500 alors que l'application fait exactement ce pour quoi elle a été conçue semble également un peu étrange. 404 décrit exactement la situation : Ressource non trouvée.

Answer 2

Je pense que vous devriez utiliser 404. Les développeurs de l'API comprendront ce que signifie 404 et suivront donc leur propre processus de débogage habituel afin de résoudre le problème. Respectez le protocole.

Answer 3

L'erreur 404 est en fait une réponse plus acceptable dans ce cas, car la ressource est vraiment introuvable. Vous pouvez toujours avoir un document d'erreur personnalisé qui explique que c'est l'identifiant de l'utilisateur qui est introuvable.

Une erreur 400 implique que le client a envoyé une syntaxe malformée, ce qui n'est pas le cas dans votre exemple. Vous ne devez donc pas utiliser ce code d'erreur. Il peut sembler que "Bad Request" soit exact, mais cela signifie en fait qu'il y a une erreur dans la syntaxe de l'en-tête de la demande.

Il ne s'agit pas non plus d'une erreur 500 car aucune erreur ne s'est produite. Il n'y a pas de problème avec le serveur web qui répond à la demande, le fait est que la demande cherche une ressource qui n'est pas présente.

404 est la seule réponse appropriée, sauf si vous voulez considérer qu'il s'agit d'une demande entièrement valide, renvoyer le statut 200 et une page expliquant que le patron demandé n'existe pas.

De mon commentaire original sur la question :

Je ne pense pas qu'une erreur de niveau 200 soit appropriée non plus, considérez les explications à W3 w3.org/Protocoles/rfc2616/rfc2616-sec10.html

Answer 4

IMHO, la réponse HTTP est no est le bon endroit pour traiter ce problème, car l'erreur ne se situe pas au niveau HTTP. Elle se situe au niveau de l'application. Une solution possible est d'utiliser la fonction Modèle d'objet nul pour renvoyer un "Patron" nul conforme à l'interface Patron, mais indiquant que cette personne n'existe pas.

---

UPDATE : J'ai été convaincu que cette réponse est fausse. Cependant, je veux la laisser en place, car c'est une réponse potentiellement valable (en fonction de détails non présentés dans la question), et je pense que les commentaires sont instructifs.

Answer 5

En général, si votre service rencontre une erreur qu'il n'est pas en mesure de traiter, mais que la demande est bien formée, je pense que vous voudrez renvoyer un code d'état 500.

Une autre raison pour laquelle je dis que 500 serait approprié est que, d'après mon expérience des services Web .NET, chaque fois que je lance une exception sur le fil (telle qu'une exception RecordNotFound), le serveur Web et le client ont toujours interprété la réponse comme étant un code d'état 500.

Quoi qu'il en soit, ce serait une bonne idée d'examiner ce liste des codes d'état http, et choisissez celui qui répond le mieux à vos besoins.