API REST 404: URI incorrect ou ressource manquante?

Question

Je suis en train de construire une API REST, mais j'ai rencontré un problème.

Il semble que la pratique acceptée dans la conception d'une API REST, c'est que si la ressource demandée n'existe pas, une erreur 404 est retourné.

Cependant, pour moi, cela alourdit inutilement l'ambiguïté. HTTP 404 est plus traditionnellement associés à une mauvaise URI. Donc en effet, nous sommes en train de dire "Soit tu as à la bonne place, mais que le dossier n'existe pas, ou il n'y a pas d'emplacement sur les Internets! Je ne suis vraiment pas sûr que l'on.."

Envisager l'URI suivante:
http://mywebsite/api/user/13

Si j'obtiens une erreur 404 en arrière, est-ce parce que l'Utilisateur 13 n'existe pas? Ou est-ce parce que mon URL doit avoir été:
http://mywebsite/restapi/user/13

Dans le passé, je viens de rentrer d'un résultat NUL avec un HTTP 200 OK code de réponse si l'enregistrement n'existe pas. C'est simple, et à mon avis, très propre, même si elle n'est pas nécessairement une pratique courante. Mais est-il une meilleure façon de le faire?

Answer 1

404 est juste le code de réponse HTTP. En plus de cela, vous pouvez fournir un corps de réponse et / ou d'autres en-têtes avec un message d'erreur plus significatif que les développeurs verront.

Answer 2

Utiliser 404 si la ressource n'existe pas. Ne pas renvoyer 200 dont le corps est vide.

Cela ressemble à l' undefined vs chaîne vide (par exemple, "") dans la programmation. Bien que très semblables, il y a certainement une différence.

404 signifie que rien n'existe à l'URI (comme une variable non définie dans la programmation). De retour 200 dont le corps est vide signifie que quelque chose n'existe pas et que quelque chose est un peu vide pour le moment (comme une chaîne vide dans la programmation).

404 ne veut pas dire que c'était un mauvais "URI". Il y a des HTTP codes qui sont conçus pour les URI des erreurs (par exemple, 414 Request-URI Too Long).

Answer 3

Comme avec la plupart des choses, "ça dépend". Mais pour moi, votre pratique n'est pas mauvais et ne va pas à l'encontre de la spécification HTTP soi. Cependant, nous allons clarifier certaines choses.

Tout d'abord, d'URI doit être opaque. Même si ils ne sont pas opaques aux gens, ils sont opaques aux machines. En d'autres termes, la différence entre http://mywebsite/api/user/13, http://mywebsite/restapi/user/13 est la même que la différence entre http://mywebsite/api/user/13 et http://mywebsite/api/user/14 c'est à dire pas le même n'est pas la même période. Si une erreur 404 serait tout à fait approprié pour http://mywebsite/api/user/14 (si ce n'est pas l'utilisateur), mais pas nécessairement la seule réponse appropriée.

Vous pouvez également revenir à un vide de réponse de 200 ou plus explicitement 204 (Pas de Contenu) de réponse. Cela permettrait de transmettre quelque chose d'autre pour le client. Cela impliquerait que la ressource identifiée par l' http://mywebsite/api/user/14 n'a pas de contenu ou n'est essentiellement rien. Cela signifie qu'il est une telle ressource. Toutefois, cela ne signifie pas nécessairement que vous demandez, il ya certains utilisateurs ont persisté dans une banque de données avec l'id 14. C'est votre souci, pas la préoccupation du client qui fait la demande. Donc, si elle fait sens pour le modèle de vos ressources, de cette façon, aller de l'avant.

Il y a quelques implications en matière de sécurité afin de donner à vos clients l'information qui permettrait de rendre plus facile pour eux de deviner légitime d'URI. Retour d'un 200 sur la rate au lieu d'une 404, peut donner au client une idée de ce que au moins l' http://mywebsite/api/user partie est correcte. Un client malveillant pourrait continuer à essayer différentes entiers. Mais pour moi, un client malveillant serait capable de deviner l' http://mywebsite/api/user de la partie de toute façon. Une meilleure solution serait d'utiliser l'UUID. c'est à dire http://mywebsite/api/user/3dd5b770-79ea-11e1-b0c4-0800200c9a66 est mieux que http://mywebsite/api/user/14. En faisant cela, vous pouvez utiliser votre technique de retour 200 sans donner beaucoup de loin.

Answer 4

404 not Found techniquement signifie que l'uri n'est pas actuellement une carte à une ressource. Dans votre exemple, je interpréter une demande d' http://mywebsite/api/user/13 qui renvoie un 404 pour insinuer que cette url est jamais mappé à une ressource. Pour le client, qui doit être la fin de la conversation.

Pour répondre aux préoccupations de l'ambiguïté, vous pouvez améliorer votre API en fournir d'autres codes de réponse. Par exemple, supposons que vous souhaitez afin de permettre aux clients d'émettre des requêtes GET de l'url http://mywebsite/api/user/13, vous souhaitez communiquer que les clients doivent utiliser l'url canonique http://mywebsite/restapi/user/13. Dans ce cas, vous souhaitez peut-être envisager la publication d'une redirection permanente, en retournant une 301 moved permanently et l'approvisionnement de l'url canonique de l' Emplacement de l'en-tête de la réponse. Ceci indique au client qu'à l'avenir les demandes qu'ils doivent utiliser l'url canonique.

Answer 5

Cet article ancien mais excellent ... http://www.infoq.info/articles/webber-rest-workflow le dit à ce sujet ...

404 Not Found - Le service est beaucoup trop paresseux (ou sécurisé) pour nous donner une raison réelle de l'échec de notre demande, mais quelle que soit la raison, nous devons en tenir compte.