Disons que j'ai un site Web où les utilisateurs peuvent télécharger et afficher leurs images. Une URL reposante à une seule image de cet utilisateur ressemblerait à: mais l'image-id-même est déjà unique, cette URL serait donc déjà assez bonne pour l'obtenir: du point de vue de la vue, le premier serait favorable, mais je devrais alors vérifier , que cette image est est reposant dans un tel cas encore préféré?
3 Réponses :
Je pense que la seconde est plus reposante pour la raison pour laquelle vous indiquez. L'URL est une hiérarchie. L'utilisateur-ID ne fait pas vraiment partie de l'identification de l'image, alors pourquoi faire partie de l'identifiant?
Faire un / users / {ID utilisateur} / images Ressource qui renvoie une liste d'URL dans le formulaire / Images / {Image-ID} pour répertorier les images que l'utilisateur a téléchargé et vous avez le meilleur des deux mondes.
Je pense que tout dépend de la sémantique et des intentions. Il semble que vous parlez d'une ressource protégée, pas d'un public disponible publiquement. Dans ce cas, votre communication est plus explicite et a le moins de surprise lorsqu'un format plus verbeux est utilisé: s'il s'agit d'une ressource publique, il ne peut être identifié que par image-ID uniquement et Ensuite, le format plus court serait plus logique:
En bref, les deux sont préférés; Les deux peuvent renvoyer la même chose "chose" mais le "contexte" est différent.
Jetons un coup d'oeil à vos URL:
/ utilisateurs : tous les utilisateurs
-
/ utilisateurs / 1 : utilisateur n ° 1
-
/ utilisateurs / 1 / images : Tous les images de l'utilisateur # 1
-
/ utilisateurs / 1 / images / 1 : l'image n ° 1 de l'utilisateur # 1
Toutes les URL ci-dessus tournent autour de la ressource "utilisateur". C'est "tous les utilisateurs", "un utilisateur", "images d'un utilisateur", etc.
-
/ images : Toutes les images
-
/ images / 1 : image n ° 1
Toutes les URL ci-dessus tournent autour de la ressource "image". C'est "toutes les images" ou "une image".
Maintenant, à la surface, cette distinction peut sembler relativement mineure, mais lors de la construction d'une API, la différence peut avoir un impact important sur la manière dont les données sont consommées.
Par exemple, disons que vous souhaitez obtenir une liste de toutes les images de l'utilisateur n ° 1, qui est préférée?
/ Utilisateurs / 1 / Images
ou
/Images?where=user.id eq 1
La première représente exactement ce que nous voulons, est plus contraint et plus facile à comprendre, cependant, cela ne signifie pas que nous ne devrions pas également soutenir le deuxième formulaire car la capacité d'interroger peut être assez utile.
Maintenant, qu'en est-il si vous souhaitez obtenir une liste d'images, avec leur utilisateur associé?
/utilisateurs/???
ou
/ images? Inclure = utilisateur
Dans ce scénario, la première URL n'a pas beaucoup de sens du tout, car nous essayons d'obtenir une liste d'images, pas d'utilisateurs, tandis que la deuxième URL représente exactement ce que nous voulons .
Maintenant, en ce qui concerne la sécurité, cela devrait idéalement être fait de manière totalement transparente pour le consommateur. Un consommateur devrait pouvoir dire "je veux toutes les images". et ne reçoit jamais toutes les images qu'elles ont accès. S'ils tentent d'accéder à une ressource spécifique qu'ils n'ont pas accès à, un code d'erreur HTTP approprié doit être renvoyé.
Malgré des idées fausses populaires, le reste n'a rien à voir avec la conception de l'URL. Vous pouvez produire des URL sous forme de chaînes générées aléatoires annexées à votre domaine et que vous êtes toujours parfaitement conforme.