REST Discoverability et HATEOAS impliquent-ils que vous pouvez modifier les URI?

J'essaie de clarifier un concept lié à la découvrabilité REST, à savoir si le fait de satisfaire la contrainte HATEOAS pour un service RESTful signifie que les URI peuvent désormais changer, car ils sont détectables et non documentés.

Cela semble ne pas suivre le concept de URIs Cool - le fait que les URI ne ' t changer, jamais. Il est également quelque peu incohérent avec le modèle du Web lui-même (qui REST devrait en principe correspondre parfaitement) - le fait que les URL sont des signets et ne changent jamais, et le fait que, une fois que vous en avez appris un, vous pouvez y accéder directement et le faire. pas besoin de passer par la racine et de la découvrir à chaque fois.

Tout commentaire à ce sujet est apprécié.

9

2 Réponses

Pour les URI cool, non, vous ne devriez jamais les changer. Ils sont les points d'entrée dans votre système. Cependant, vous devriez en avoir très peu si vous voulez avoir la possibilité de faire évoluer le reste de la structure d'URI de votre système à l'avenir.

Pour les URI non Cool, ils peuvent en effet changer au fil du temps . J'ai récemment écrit un blog sur ce sujet, car je trouve les informations de REST. capacité à me permettre de faire évoluer mon système au fil du temps pour être incroyablement utile.

Assurez-vous que la documentation de votre API indique clairement que seuls les quelques URI Cool de votre système doivent être codés en dur par les clients, et que tout autre URI doit être détecté au moment de l'exécution via l'hypermédia. Considérez-les comme une adresse de pointeur C: personne ne se soucierait de la valeur hexadécimale d'une variable de pointeur, mais ils voudraient certainement qu'elle pointe vers un emplacement valide en mémoire. Il en va de même pour vos URI non Cool: leur structure importe peu, mais le fait qu’ils aient été récupérés au moment de l’exécution par le biais de conversations avec votre serveur les rend valides.

6
ajouté
Merci pour la réponse rapide. J'ai lu l'article mais je ne comprends toujours pas bien certaines choses - tout d'abord, n'est-ce pas à quoi sert le versionnage de l'API? et deuxièmement, devrait-il y avoir AUCUNE documentation? D'après ce que je comprends, dans une implémentation RESTful pure, il n'y aurait pratiquement aucune documentation. Serait-il préférable d’utiliser uniquement des URL cool et de faire une version différente de l’API pour un changement aussi radical?
ajouté l'auteur Eugen, source
Donne un sens d'un point de vue pragmatique. Cependant, je pensais plutôt à une implémentation pure RESTful, avant la nécessité de faire des compromis. S'agissant de la gestion des versions et d'une approche pragmatique, je m'intéresse à l'expérience pratique d'une API consommée par un grand nombre de clients. Cela peut-il réellement être modifié? De manière pragmatique, je pense que cela n’est pas possible, et que la gestion des versions est le seul moyen viable, en particulier compte tenu du fait qu’il existe également d’autres avantages à conserver des URLs froides. Merci pour les commentaires intéressants.
ajouté l'auteur Eugen, source
La gestion des versions d'une API uniquement pour maintenir la compatibilité de la structure URI pose les mêmes problèmes que d'avoir un WSDL pour chaque version de votre service Web: vous ne faites pas évoluer votre service, vous en ajoutez de nouvelles versions (principalement dupliquées) à chaque fois. Il vous faudra tester, maintenir, documenter, etc. Faites-le et dites au revoir à un énorme avantage de REST: évolution dynamique de vos "contrats" et découplage merveilleux entre client et serveur.
ajouté l'auteur Brian Kelly, source
Et pour ce qui est de ne pas avoir de documentation, bien sûr, lorsque tout le monde du logiciel aura développé une expertise avec REST, ce sera parfaitement logique. Il y aura toujours des débutants qui voudront utiliser votre API, et ne leur donner aucun moyen de travailler n'a aucun sens pour moi. Bien sûr, un expert REST pourrait probablement s’asseoir et comprendre tout cela, mais ce n’est pas le monde dans lequel nous vivons. Documentez vos types de supports et la sémantique de chaque ressource et donnez un exemple de code qui montre comment des clients bien construits doivent être construits, et ça ira.
ajouté l'auteur Brian Kelly, source
Je n'ai pas vu d'API RESTful évoluer sans versioning des adresses URI, et je pense que cela est dû au fait que la plupart des programmeurs sont attirés par l'état d'esprit de "contrat d'abord" créé par des technologies telles que WSDL, CORBA IDL, etc. possible avec REST de s’éloigner de cette pensée, et je vous encourage à essayer de faire de même.
ajouté l'auteur Brian Kelly, source

Il doit y avoir de la documentation. MediaTypes et Link Relations constituent un point de couplage et le client et le serveur doivent le comprendre. C'est pourquoi HTML, ATOM et RSS ont des normes.

En termes de fonctionnement, je peux voir que je n’ai pas de documentation. Je n'ai pas besoin de savoir ce que Yahoo a sur sa page d'accueil car je peux le découvrir. De la même manière, un client de mon service n'a pas besoin de connaître une nouvelle fonctionnalité que je publie. Ils peuvent trouver que le lien existe et utiliser ensuite la relation de lien pour voir ce qu’il fait.

La documentation porte donc sur les normes et le protocole à utiliser, mais pas sur le fonctionnement de l'application.

0
ajouté