Chaîne de requête dans l'URL des ressources REST

Question

J'ai eu une discussion avec un collègue aujourd'hui autour de l'utilisation de la chaîne de recherche dans l'url REST. Prendre que ces 2 exemples

1. http://localhost/findbyproductcode/4xxheua
2. http://localhost/findbyproductcode?productcode=4xxheua

Mon attitude a été l'url doit être conçu de manière que dans l'exemple 1. C'est plus propre et ce que je pense est correct à l'intérieur de repos. À mes yeux, vous seriez tout à fait correct pour retourner une erreur 404 à partir de l'exemple 1 si le code produit n'existe pas, où, comme dans l'exemple 2 de retourner une erreur 404 aurait tort que la page doit exister. Sa position était qu'il n'a pas vraiment d'importance et qu'ils font tous les deux la même chose.

Comme aucun de nous, où en mesure de trouver des preuves concrètes (admitably ma recherche n'était pas vaste), je voudrais savoir l'avis des autres sur ce point.

Cordialement Colin G

Answer 1

Il n'y a pas de différence entre les deux Uri du point de vue du client. Les uri sont opaques pour le client. Utilisation selon la valeur des cartes plus proprement dans votre serveur de côté les infrastructures.

Aussi loin que le RESTE, c'est il n'y a absolument aucune différence. Je crois que la raison pour laquelle tant de gens ne croient que c'est seulement la partie chemin qui identifie la ressource est à cause de la ligne suivante dans la RFC 2396

Le composant de requête est une chaîne de informations pour être interprété par le de la ressource.

Cette ligne a été changé plus tard dans la RFC 3986 :

Le composant de requête contient non hiérarchique des données, ainsi que données dans le composant de chemin d'accès (Section 3.3), sert à identifier une ressource

À mon humble avis, cela signifie à la fois la chaîne de requête et de segment de tracé sont fonctionnellement équivalent quand il s'agit de l'identification d'une ressource.

---

Mise à jour de l'adresse de Steve commentaire.

Pardonnez-moi si je m'oppose à l'adjectif "propre". Il est bien trop subjectif. Vous avez un point bien que j'ai manqué une partie importante de la question.

Je pense que la réponse à savoir si le retour 404 dépend de ce que la ressource est récupérée. Est-ce une représentation d'un résultat de recherche, ou est-il une représentation d'un produit? Pour savoir ce que vous vraiment besoin de regarder la relation de lien qui nous a conduit à l'URL.

Si l'URL est censé retourner un Produit, la représentation d'une 404 doit être retourné si le code n'existe pas. Si l'URL renvoie un résultat de recherche, alors il ne devrait pas retourner une erreur 404.

Le résultat final est que ce que l'URL ressemble n'est pas le facteur déterminant. Cela dit, c'est la convention que les chaînes de requête sont utilisées pour retourner des résultats de recherche de sorte qu'il est plus intuitif à utiliser que le style de l'URL lorsque vous ne voulez pas retourner une erreur 404.

Answer 2

Typique de la REST API, exemple #1 est plus correct. Les ressources sont représentés comme des URI et #1 ne fait que de plus en plus. Retourner une erreur 404 lorsque le code produit n'est pas trouvé, est absolument le bon comportement. Cela dit, je voudrais modifier #1 légèrement à être un peu plus expressif comme ceci:

http://localhost/products/code/4xheaua

Regarder d'autres bien conçu Api REST - regardez, par exemple, StackOverflow. Vous avez:

stackoverflow.com/questions
stackoverflow.com/questions/tagged/rest
stackoverflow.com/questions/3821663

Ce sont tous des façons différentes d'obtenir des "questions".

Answer 3

Il y a deux cas d'utilisation pour l'OBTENIR

1. Obtenir un identifié de manière unique ressource
2. Recherche de ressource(s) sur base de critères donnés

Cas D'Utilisation 1 Exemple:

/produits/4xxheua
Obtenir un identifié de manière unique produit, retourne 404 si elle ne trouve pas.

Cas D'Utilisation 2 Exemple:

/produits?taille=grand&couleur=rouge
Pour rechercher un produit, retourne la liste de correspondance des produits (de 0 à plusieurs).

Si nous regardons à-dire l'API Google Maps, nous pouvons voir qu'ils utilisent une chaîne de requête pour la recherche.

par exemple http://maps.googleapis.com/maps/api/geocode/json?address=los+angeles+ca&sensor=false

De sorte que les deux styles sont valables pour leur propre usage.

Answer 4

IMO le composant de chemin d'accès doit toujours indiquer ce que vous souhaitez récupérer. Une URL de la forme http://localhost/findbyproductcode ne dis seulement que je veux récupérer quelque chose par le code du produit, mais quoi exactement?

Afin de vous récupérer des contacts avec http://localhost/contacts et les utilisateurs avec http://localhost/users. La chaîne de requête est utilisé uniquement pour l'extraction d'un sous-ensemble d'une telle liste est basée sur les attributs des ressources. La seule exception à cette règle est lorsque ce sous-ensemble est réduit à un enregistrement en fonction de la clé primaire, puis vous utilisez quelque chose comme http://localhost/contact/[primary_key].

C'est mon approche, votre kilométrage peut varier :)

Answer 5

La fin de ces deux Uri n'est pas très important Paisiblement.

Cependant, l '" findbyproductcode partie pourrait certainement être plus reposant. Pourquoi ne pas simplement http://localhost/product/4xxheau ?

Dans mon expérience limitée, si vous avez un identifiant unique, alors il serait un aspect propre à la construction de l'URI comme .../produit/{id} Cependant, si le code produit n'est pas unique, alors je pourrais le concevoir plus comme #2.

Cependant, comme Darrel a observé, le client ne doit pas attention à ce que l'URI ressemble.