2010-08-11 5 views
2

Je développe une API RESTful. L'une des URL permet à l'appelant de demander l'enregistrement pour une personne spécifique par identifiant.Méthode REST pour gérer les données manquantes

Quelle est la valeur conventionnelle de retour de l'enregistrement pour cet ID n'existe pas? Le serveur devrait renvoyer un objet vide ou peut-être un 404, ou quelque chose d'autre?

Merci.

Répondre

1

404, ou peut-être 410 (Gone) si elle était là avant (mais 404 n'est pas faux dans ce cas non plus).

Comme toujours avec REST, il est également préférable d'envoyer une représentation (même avec un code 4xx) pour indiquer au client que la ressource n'existe pas et lui dire quelles actions possibles il peut prendre à partir de là.

2

Généralement, je renvoie une erreur 404 de mon API RESTful dans ces cas, en fonction de la convention utilisée par CodeIgniter Rest Server.

Cela fonctionne bien pour la plupart, et est la solution la plus "correcte" et "pure". Cependant, l'erreur 404 peut rendre un peu plus difficile la gestion de ces cas "manquants" sur le client car vous pourriez avoir besoin d'un gestionnaire d'erreurs distinct au lieu de ne rien faire car vous avez récupéré un objet vide.

Je recommanderais de soupeser les avantages et les inconvénients des deux approches et de mettre en œuvre l'approche qui vous convient le mieux.

+0

Comment le client fait-il la distinction entre un chemin d'URL qui n'existe pas et un enregistrement qui n'existe pas? – Ralph

+0

Il n'y a pas de distinction puisqu'elle n'existe pas. Cependant, j'aime bien la suggestion de @ Bruno d'envoyer une représentation avec le code 404 - cela pourrait être utilisé pour faire une telle distinction. –

0

En plus de considérer 404, je considérerais la possibilité de retourner une représentation de "vide": Considérez une recherche de Google pour le mot klinjeraliknoplidocus. Au moment de la rédaction de ce document, il renvoie 200 OK avec "aucune correspondance" et des suggestions non comment aller de l'avant. Il ne renvoie pas 404, puisque l'URI http://www.google.com/search?q=klinjeraliknoplidocus identifie réellement quelque chose, à savoir "Tous les documents connus de Google qui sont liés au terme klinjeraliknoplidocus". Bientôt, cette page va apparaître là-bas.

Alors:

  • si vous définissez votre fonction de recherche en retour zéro ou plusieurs éléments avec cet ID, puis 200 et une réponse vide est logique.
  • Si vous définissez votre fonction de recherche comme renvoyant exactement un élément, alors 404 (ou 410) est logique.
+0

Que diriez-vous de 400 (mauvaise demande)? De cette façon, je peux distinguer entre une URL mal typée (400) et un identifiant qui n'existe pas. – Ralph

+0

Je pense que la demande incorrecte devrait être réservée aux erreurs syntaxiques. Un URI identifiant des déchets n'est pas syntaxiquement incorrect. Un en-tête qui est malformé (par exemple 'If-None-Match: abc' guillemets manquants autour de l'ETag) est mal formé; un document XML avec des erreurs de syntaxe dans un PUT ou POST est syntaxiquement incorrect, les deux pourraient causer 400s. Faire un GET pour/customers? Q = 12345 ou/customer/id/12345 n'est pas en soi syntaxiquement incorrect. 200 ou 404 doit être utilisé si l'ID client n'existe pas en fonction de la nature de la définition de la ressource. – mogsie

Questions connexes