REST - Prise en charge de plusieurs identifiants possibles

Question

Pour le site sur lequel nous travaillons, nous sommes en train d'améliorer nos URL pour un type de ressource - en particulier, nous nous éloignons des ID numériques vers des chaînes descriptives uniques. Un exemple similaire serait de passer de l'identification des utilisateurs par ID de base de données numérique à leur identification par nom d'utilisateur (pas notre cas spécifique, mais analogue). Ainsi, une URL pour accéder aux informations d'un utilisateur utilisé pour ressembler à:

/users/48573 

Et maintenant il ressemble à

/users/thisisausername. 

Le seul problème est que nous avons encore besoin de pouvoir les récupérer par ID numériques en quelque sorte , pour les utilisateurs hérités de l'API. Nous n'avons pas besoin des URL REST elles-mêmes pour rediriger (par exemple, /users/48573 ne doit pas rediriger vers /users/thisisausername), nous avons juste besoin d'une méthode pour obtenir les bonnes données en utilisant l'ancien identifiant. La solution devrait soit fournir un moyen alternatif d'accéder aux informations de l'utilisateur (ce qui inclut commodément le nouvel identifiant, le nom d'utilisateur) par ID, soit accéder uniquement au nom d'utilisateur par ID. Certaines solutions possibles peuvent être:

• L'utilisation d'un noeud pour spécifier une autre méthode d'identification, par ex. Utilisation d'un paramètre de requête pour spécifier une autre méthode d'identification, par ex. /users/48573?fetchby=id ou /users/48573?byid=true
• Traiter le nom d'utilisateur par ID comme une autre ressource, par ex. /identifiers/username/48573

Lequel (le cas échéant) est le plus proche du bon REST? Comment traiteriez-vous le problème?

Answer 1

Votre première option est probablement la meilleure.

Recherche d'utilisateurs par ID:

/users/id/48573 

Recherche d'utilisateurs par nom court:

/users/name/thisisausername 

Si elles quittent que le paramètre de chemin, vous pouvez toujours défaut à votre nouveau format de nom d'utilisateur court.

Une autre option que je l'ai vu un peu est d'utiliser des paramètres de la requête comme suit:

/users?id=48573 
/users?name=thisisausername 

Je pense que le premier semble un peu plus propre et plus lisible.

Answer 2

je considère qualifier la chaîne avec un suffixe en option:

/users/48573/id 

/users/48573/name 

Si vous recevez une chaîne sans le suffixe:

/users/48573 

vous vérifiez la chaîne et voir si elle est un ID ou Nom.

Si vous obtenez seulement une pièce d'identité valide, mais pas un nom alors il est une recherche par ID équivalent à:

/users/48573/id 

Si vous obtenez seulement un nom à l'époque, il y a une recherche par nom équivalent à:

/users/48573/name 

Si vous pouvez récupérer la valeur par ID ou le nom puis vous revenez d'une erreur de réponse 300 et le retour des liens vers les deux possiblités au client:

/users/48573/id 

/users/48573/name 

Les consommateurs existants continuent de fonctionner «tels quels», à l'exception de l'apparition occasionnelle de paires ID/nom en double où ils reçoivent la nouvelle erreur de réponse 300.

Answer 3

Votre API n'est pas RESTful si c'est un problème. Pour quote Roy Fielding:

Une API REST ne doit pas définir de noms ou de hiérarchies de ressources fixes (un couplage évident entre le client et le serveur). Les serveurs doivent avoir la liberté de contrôler leur propre espace de noms. Au lieu de cela, autorisez les serveurs à indiquer aux clients comment créer des URI appropriées, comme dans les formulaires HTML et les modèles d'URI, en définissant ces instructions dans les types de média et les relations de liaison. [L'échec ici implique que les clients supposent une structure de ressources due à des informations hors bande, comme un standard spécifique au domaine, qui est l'équivalent orienté vers les données du couplage fonctionnel de RPC]. Une API REST doit être entrée sans aucune connaissance préalable au-delà de l'URI (marque-page) et de l'ensemble des types de média normalisés appropriés pour le public visé (c'est-à-dire que tout client susceptible d'utiliser l'API devrait comprendre). . À partir de ce moment, toutes les transitions d'état d'application doivent être pilotées par la sélection par le client des choix fournis par le serveur qui sont présents dans les représentations reçues ou impliqués par la manipulation de ces représentations par l'utilisateur. Les transitions peuvent être déterminées (ou limitées par) les connaissances du client sur les types de média et les mécanismes de communication de ressources, qui peuvent tous deux être améliorés à la volée (par exemple, code à la demande). [L'échec ici implique que les informations hors bande conduisent l'interaction à la place de l'hypertexte.]

Answer 4

Je pense que l'ajout d'un segment/préfixe est la meilleure réponse. Comme ce sont des clés secondaires uniques, ce n'est pas la même chose que search (qui renvoie un ensemble d'éléments), donc l'utilisation de paramètres de requête (qui ne sont pas mis en cache) ne semble pas être le meilleur choix.

Personnellement, je prévois d'utiliser un préfixe de segment de chemin délimité par "=", comme "name =" ou "email =":

user/123456 
user/name=john.doe 
user/email=john.doe@john.doe 

Ceci est fonctionnellement équivalent à l'ajout d'un segment de chemin (par exemple " user/name/john.doe "), mais il me semble que cela ressemble plus au modèle conceptuel. Bien sûr, ceci est un détail insignifiant, puisque les API RESTful ne devraient pas spécifier une structure d'URI fixe de toute façon.

Ne pas utiliser les paramètres de la requête permet également des sous-ressources pour accéder naturellement:

user/name=john.doe/inbox/df87bhJXrg63 

Cadres comme JAX-RS de support Java en utilisant tous les délimiteur que vous voulez:

@GET 
@Path("user/{id}") 
User getUser(@PathParam("id") UUID id); 

@GET 
@Path("user/name={name}") 
User getUserByName(@PathParam("name") String name); 

@GET 
@Path("user/email={email}") 
User getUserByEmail(@PathParam("email") String email); 

Answer 5

Tout à fait une vieille question, mais J'ai eu le même et finalement trouvé la solution: utilisez regex dans votre chemin param.

Voilà comment je codé ce cas d'utilisation

@GET 
@Path("/{id : \\d+}") 
@Produces(APPLICATION_JSON) 
public Response getById(@PathParam("id") long id) { 
<<your code>> 
} 

@GET 
@Path("/{name}") 
@Produces(APPLICATION_JSON) 
public Response getByName(@PathParam("name") String name) { 
<<your code>> 
}