Exemples réels pour HATEOAS (architecture REST)
comme tout le monde l'a peut-être remarqué, il y a beaucoup d'API REST fausses/rudimentaires dans la nature (qui implémentent une API HTTP et l'appellent REST sans suivre l'hypertexte en tant que moteur) de l'exigence de l'état d'application, ce qui a conduit à la fameuse diatribe de Roy T. Fielding , l'homme qui a le premier spécifié le paradigme REST).
Je n'ai pas pu trouver d'exemples pratiques d'une implémentation REST vraiment hypertexte avec les définitions de type de média spécifiques à l'application associées pour les transitions d'état.
Existe-t-il des exemples accessibles au public de telles implémentations?
Ce n'est pas une implémentation dans le sens de l'exécution de code, mais j'aime vraiment l'article " Comment obtenir une tasse de café " sur InfoQ. Il décrit le processus de commande d'un café chez Starbucks comme un protocole RESTful. Cela va au-delà du "tout est une ressource" typique REST article d'introduction et se concentre sur HATEOAS. Fortement recommandé.
Que diriez-vous de Sun Cloud API ? Depuis l'introduction:
L'API ne suppose aucune structure particulière dans l'espace URI. Le point de départ est un URI, fourni par le fournisseur de services cloud, qui identifie le cloud lui-même. La représentation du cloud contient des URI pour les autres ressources du cloud, ainsi que pour les opérations qui peuvent y être effectuées (par exemple le déploiement et le démarrage de machines virtuelles).
Le backstory pourrait également être utile.
Netflix possède une API REST basée sur HATEOAS qui inclut des liens dans le cadre des ressources.
J'ai réalisé que cela avait été demandé il y a quelque temps, mais j'ai essayé de démontrer un "bon" flux REST API pour un exemple simple. J'ai essayé de suivre les règles de Roy pour REST - cela pourrait peut-être aider: Exemple d'API utilisant REST
La RESTfulness de Sun Cloud API n'est-elle pas réellement abordée dans le quatrième point de Roy:
A REST ne doit pas définir de noms ou de hiérarchies de ressources fixes (un couplage évident entre client et serveur). Les serveurs doivent avoir la liberté de contrôler leur propre espace de noms. Au lieu de cela, autorisez les serveurs à expliquer aux clients comment pour construire des URI appropriés, comme cela se fait dans les formulaires HTML et les modèles d'URI, en définissant ces instructions dans les types de médias et les relations de liens. [L'échec ici implique que les clients supposent une structure de ressources en raison d'informations hors bande, comme un domaine standard spécifique, qui est l'équivalent orienté données du couplage fonctionnel du RPC].
Exemple 1 Noms de ressource fixes dans une héritière définie:
De l'API Sun Cloud: "... la représentation d'un VDC comprendra des représentations des clusters qui l'habitent, qui à leur tour incluent des représentations des VM au sein de chaque cluster."
Exemple 2 informations hors bande, comme une norme spécifique au domaine:
Vous devez avoir le contenu de la page wiki (informations hors bande) pour savoir que le "mécanisme de communication des ressources" pour le champ de ressource Cloud "uri" est GET.