qu'est-ce que l'hypermédia, les contrôles hypermédia, les formats hypermédia
Je lis actuellement le livre "Rest in practice". Je ne parviens pas à comprendre la terminologie suivante Hypermédia, format hypermédia, contrôles hypermédia, protocole d'application de domaine. L'auteur suggérait la nécessité d'un format hypermédia spécifique au domaine. Je pouvais à peine les comprendre. J'ai recherché ces termes sur Google, mais je n'ai pas trouvé de bonne réponse. Quelqu'un peut-il expliquer ces terminologies et pourquoi nous avons besoin de formats hypermédia spécifiques au domaine au lieu de application/xml?
Hypermédia = le fait que le client et le serveur parlent en termes de représentation uniforme, par exemple: hyperliens.
HyperMedia Control = Une ressource doit avoir une opération sur elle. Ainsi, par exemple, un produit est représenté par le lien hypertexte domaine/produit/001, puis la ressource peut être exploitée (modifiée et supprimée) par le domaine de contrôle hypermédia/produit/001/modifier et le domaine/produit/001/supprimer.
La plus grande différence réside dans l'approche. les systèmes procéduraux écrivent d'abord les opérations sous forme de transitions d'état en code séquentiel (Java, etc.), puis les interactions sont fabriquées sous forme de liens hypertexte pour fournir HATEOAS.
Mais les systèmes considérés comme des interactions modélisent directement les interactions et fournissent donc directement des hyperliens. Un exemple d'exemple est http://www.masterkube.com/hateoas_technology.html est ici.
J'espère que cela t'aides.
Il y a beaucoup de confusion à ce sujet, car la plupart des applications qui s'appellent REST n'utilisent pas l'hypermédia et ne le sont pas REST du tout).
Hypermedia est une généralisation d'hypertexte pour un contenu autre que HTML. Vous pouvez dire que l'hypertexte est un sous-ensemble d'hypermédia. L'hypermédia peut être HTML dans un navigateur, avec tous les liens, boutons et tout ce qui est rendu pour que vous puissiez parcourir un site Web, ou il peut s'agir d'un document XML ou JSON destiné à être analysé par un client automatisé qui suivra également des liens et des actions comme un humain ferait avec un navigateur, en cliquant sur les liens et boutons rendus.
HATEOAS signifie l'interaction d'un client avec une application REST doit être pilotée par hypermédia, ou pour le dire simplement, le le client doit obtenir tous les URI pour chaque ressource dont il a besoin en suivant les liens dans la représentation des ressources elles-mêmes, et non en s'appuyant sur des informations hors bande, comme les modèles d'URI donnés dans la documentation, comme le font de nombreuses API.
C'est plus simple qu'il n'y paraît. Cela signifie simplement que l'interaction entre un client et une application REST doit être exactement comme un humain parcourant un site Web. Prenez Stack Overflow lui-même par exemple. Il y a des utilisateurs, des questions et des réponses. Quand vous voulez pour voir une liste de vos questions, vous n'allez pas sur un site de documentation, obtenez un modèle d'URI pour lister vos questions, remplissez un espace réservé avec votre identifiant et collez-le sur votre brownser. Vous cliquez simplement sur un lien vers un autre document décrit comme la liste des questions, et vous ne vous souciez même pas de l'URI exact. C'est ce que HATEOAS signifie dans la pratique.
Un hypermedia forma t définit le contrat entre le client et le serveur. Il s'agit du format de données activé par hyperlien que vous utilisez pour une représentation particulière d'une ressource dans une application hypermédia. Par exemple, si vous avez une ressource utilisateur, vous devez documenter exactement ce que les clients doivent attendre d'une représentation de cette ressource et comment analyser la représentation pour extraire les informations. Avant d'interagir avec votre API, vos clients doivent implémenter un analyseur pour extraire les informations, ils doivent savoir quelles sont les propriétés de la ressource et ce qu'elles signifient, quelles relations de liaison elles devraient attendre et quelles transitions d'état sont disponibles, etc.
Contrôles hypermédia sont les combinaisons de méthodes de protocole et de relations de lien dans un format hypermédia qui indiquent au client quelles transitions d'état sont disponibles et comment les effectuer. Par exemple, une question peut avoir un rel=post_answer lien qui attend une représentation Answer comme la charge utile d'une méthode POST et créera une nouvelle ressource Answer qui lui est associée.
Une fois que vous avez défini un ensemble de formats hypermédia, vous avez besoin d'un type de média spécifique au domaine pour déterminer exactement quel format hypermédia est utilisé pour une interaction particulière. Un type de support générique comme application/xml indique uniquement au client comment analyser le format de données, il ne dit rien sur les informations extraites par l'analyseur. Par exemple, supposons qu'un document ait le type de support application/vnd.mycompany.user.v1+xml, le client sait qu'il s'agit d'une représentation de la version 1.0 de la ressource utilisateur au format XML. Si vous modifiez la ressource en ajoutant ou en supprimant des propriétés, des liens, etc., vous pouvez modifier le numéro de version et les clients ne s'arrêteront pas, car ils peuvent demander la version pour laquelle ils ont été implémentés en utilisant l'en-tête Accept. Vous pouvez également fournir plusieurs formats pour la même ressource, comme XML ou JSON, et même une représentation assez lisible par l'homme en HTML.
Lorsque vous enveloppez tout ensemble - le protocole sous-jacent, HTTP; les contrats définis par les formats hypermédia et les types de média - vous avez votre Domain Application Protocol, qui est l'ensemble des ressources et des transitions d'état disponibles annoncées par votre application.
Inutile de dire que 99% des soi-disant REST API que vous trouverez sur Internet ne suivent pas tout cela. La plupart d'entre elles sont simplement des API HTTP qui suivent certaines des = REST contraintes, parfois parce qu'elles n'ont pas vraiment besoin de toutes, parfois parce que c'est ce que les développeurs pensaient REST est vraiment.