qu'est-ce que l'hypermédia, contrôles hypermédia, formats hypermédia
je suis en train de lire le livre "Rest in practice". Je suis incapable de 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 propre au domaine. Je pouvais à peine comprendre. J'ai cherché ces Termes sur Google, mais je n'ai pas trouvé la bonne réponse. Est-ce que quelqu'un peut expliquer ces terminologies et pourquoi nous avons besoin de formats hypermédia spécifiques au domaine plutôt que d'applications/xml ?
2 réponses
hypermédia = le fait que le client et le serveur parlent en termes d'une certaine représentation uniforme par exemple: liens hypertextes.
contrôle hypermédia = une ressource doit faire l'objet d'une opération. Ainsi, par exemple, un produit est représenté par l'hyperlien domaine / produit / 001 ensuite ressource peut être exploitée (édité et supprimé) par l'hypermédia de contrôle de domaine/produit/001/modifier et de domaine/produit/001/supprimer.
La plus grande différence est 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 d'hyperliens pour livrer HATEOAS.
mais les systèmes considérés comme des interactions modélisent directement les interactions et fournissent donc directement des hyperliens. Un exemple est http://www.masterkube.com/hateoas_technology.html est ici.
J'espère que cela vous aidera.
il y a beaucoup de confusion à ce sujet, parce que la plupart des applications qui s'appellent repos n'utilisent pas hypermédia et ne sont pas repos du tout.
Hypermédia est une généralisation de l'hypertexte pour un contenu autre que HTML. Vous pouvez dire par hypertexte est un sous-ensemble de l'hypermédia. Hypermedia peut être HTML dans un navigateur, avec tous les liens, les boutons et tout ce qui est rendu de sorte que vous pouvez parcourir un site web, ou il peut être un document XML ou JSON destiné à être analysé par un système automatisé client qui suivra également des liens et des actions comme un humain ferait avec un navigateur, en cliquant rendu des liens et des boutons.
HATEOAS signifie que l'interaction d'un client avec une application REST doit être pilotée par hypermédia, ou pour le dire simplement, 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, pas en se basant sur des informations hors bande, comme les modèles D'URI donnés dans la documentation, autant D'API faire.
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 le débordement de la pile lui-même par exemple. Il y a des utilisateurs, des Questions et des réponses. Lorsque vous voulez voir une liste de vos questions, vous n'allez pas sur un site de documentation, vous n'obtenez pas un modèle D'URI pour lister vos questions, vous remplissez un espace réservé avec votre ID utilisateur et vous le collez sur votre brownser. Vous cliquez simplement sur un lien vers un autre document décrit comme la liste de questions, et vous ne vous souciez même pas de ce que L'URI exacte est. C'est ce que HATEOAS signifie dans la pratique.
hypermédia format définit le contrat entre le client et le serveur. C'est le format de données hypertexte 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 devraient attendre d'une représentation de cette ressource et comment analyser la représentation pour extraire l'information. Avant d'interagir avec votre API, vos clients doivent mettre en œuvre un analyseur pour extraire l'information, ils doivent savoir quelles propriétés la ressource possède et ce qu'elle signifie, quelles relations de lien ils doivent s'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 liens dans un format hypermédia qui dit au client quelles sont les transitions d'État disponibles et comment les effectuer. Par exemple, une Question peut avoir un rel=post_answer
lien qui s'attend à une représentation de la réponse comme charge utile d'une méthode POST et qui créera une nouvelle ressource de réponse liée à celle-ci.
une fois que vous avez défini un ensemble de formats hypermédia, vous avez besoin d'un type de support spécifique au domaine déterminer exactement quel format hypermédia est utilisé pour une interaction particulière. Un type de média générique comme application/xml
dit seulement le client comment analyser le format de données, il ne dit rien sur l'information extraite par l'analyseur. Par exemple, disons qu'un document a le type de média application/vnd.mycompany.user.v1+xml
, le client sait qu'il s'agit d'une représentation version 1.0 de la ressource Utilisateur en format XML. Si vous changez la ressource en ajoutant ou en supprimant des propriétés, des liens, etc., vous pouvez changer le numéro de version et les clients ne casseront pas, puisqu'ils peuvent demander la version pour laquelle ils ont été implémentés en utilisant le Accept
en-tête. Vous pouvez également fournir des formats alternatifs et / ou substituts pour la même ressource, comme XML ou JSON, et même une représentation assez lisible en HTML.
quand vous emballez tout ensemble -- le protocole sous-jacent, HTTP; Les contrats définis par les formats hypermédia et les types de médias -- vous avez votre Domaine D'Application Du Protocole, qui est l'ensemble des ressources disponibles et des transitions d'état annoncé par votre application.
inutile de dire, 99% des APIs soi-disant repos vous trouverez autour de l'internet ne suivez pas tout cela. La plupart D'entre eux sont simplement des API HTTP qui suivent certaines des contraintes REST, parfois parce qu'ils n'en ont pas vraiment besoin, parfois parce que c'est ce que les développeurs pensaient que REST est vraiment.