HATEOAS : description concise

Question

J'essaie d'avoir une compréhension claire et concise de HATEOAS, et je ne suis en aucun cas un expert en matière de REST. (Je pense que j'ai compris, grâce à ce qui suit http://www.looah.com/source/view/2284 ).

Quelqu'un peut-il suggérer un blog/article aussi intéressant concernant HATEOAS ?

Answer 1

La contrainte hypermédia (anciennement connue sous le nom de HATEOAS) est une contrainte utilisée pour donner des instructions à l'agent utilisateur.

En incluant des liens dans les représentations renvoyées, le serveur peut soulager l'agent utilisateur de la charge de travail suivante déterminer quelles actions peuvent être prises sur la base de l'état actuel de l'application et savoir avec qui interagir pour atteindre cet objectif.

Comme le serveur n'a aucune connaissance de l'état actuel de l'agent utilisateur autre que ce qu'il reçoit dans une requête, il est important que l'agent utilisateur essaie d'éviter d'utiliser un état autre que les représentations renvoyées par le serveur. Cela garantit que les actions disponibles fournies par le serveur sont basées sur la compréhension la plus complète possible de l'état de l'agent utilisateur.

Un agent utilisateur conforme à la contrainte Hypermédia agit comme une machine à état, où les transitions d'état sont causées par les liens suivants disponibles dans la représentation actuelle. La représentation renvoyée devient le nouvel état.

Les avantages de cette approche peuvent être un très agent utilisateur léger . Il nécessite très peu de code pour gérer l'état, car ses actions doivent être basées uniquement sur la réponse reçue et le lien qui a récupéré cette réponse. Le site le code de l'agent utilisateur devient déclaratif et réactif, plutôt que des séquences impératives de recevoir ceci, puis de faire ceci, puis de faire cela, vous avez simplement la mécanique pour suivre les liens et de nombreux cas de QUAND vous recevez ceci, puis faites cela.

Pour un exemple Pour comprendre comment cela fonctionne, il suffit de consulter votre navigateur Web et un site Web qui n'utilise pas Javascript. Le navigateur vous présente des options basées sur des liens dans le HTML. Lorsque vous suivez ce lien, le navigateur remplace son état actuel par le nouvel état récupéré lorsque vous avez suivi le lien. Le bouton retour fonctionne (ou du moins devrait fonctionner) parce que vous récupérez l'état d'un lien dans votre historique. Le navigateur ne devrait pas se soucier de la façon dont vous êtes arrivé sur la page, car l'état devrait être entièrement basé sur la représentation récupérée.

Ce modèle de "gestion des états peut être très contraignant car l'état actuel de votre application est basé sur une seule réponse du serveur. Cependant, des applications complexes peuvent être construites en utilisant un ensemble d'agents utilisateurs travaillant ensemble. . C'est une partie de ce qu'AJAX réalise, car il permet à un agent utilisateur distinct d'être utilisé pour faire des demandes séparées et donc, en fait, de gérer une autre machine d'état. Malheureusement, la plupart du temps, les gens reviennent à un style RPC lorsqu'ils commencent à faire des requêtes javascript, ce qui est regrettable compte tenu de l'asynchronie naturelle de Javascript.

Answer 2

HATEOAS en quelques mots : Dans les données que vous produisez, faites référence aux autres ressources en utilisant des URI, et non des ID.

Comme toutes les définitions courtes, la définition que je viens de donner est erronée à bien des égards, mais elle devrait vous faire comprendre ce qu'est l'essentiel de HATEOAS.

Maintenant, une explication un peu plus longue.

Selon le principe HATEOAS, l'état de votre application doit progresser grâce à des liens hypertextes. Imaginez que vous naviguez sur l'internet. Vous devez d'abord taper une adresse dans la barre d'adresse. À partir de ce moment-là, votre navigation n'avance pratiquement que grâce aux clics sur les liens : vous cliquez sur un lien et vous arrivez sur une autre page. Un autre clic et voilà une autre page qui apparaît. Comment le navigateur pouvait-il vous faire passer de la première page à la deuxième, puis à la troisième ? Il utilisait les URL codées dans <a> éléments.

De même, si vos applications REST génèrent ce résultat

<accomodation>
  <hotel info="http://example/hotel/0928374" price="200"/>
  <guest-house info="http://example/guest-h/7082" price="87"/>
</accomodation>

alors l'application réceptrice n'aura pas besoin d'accéder à des sources de connaissances externes pour savoir que le premier hôtel est disponible à l'adresse http://example/hotel/0928374 et le second à http://example/guest-h/7082 .

D'un autre côté, si votre application génère des réponses avec des ID tels que

<accomodation>
  <hotel id="0928374" price="200"/>
  <guest-house id="7082" price="87"/>
</accomodation>

l'application réceptrice devra savoir à l'avance comment les ID doivent être composés avec des préfixes pour obtenir l'URI auquel les informations relatives à chaque logement sont disponibles (par exemple "ajouter http://example/ à chaque demande, puis ajoutez hotel pour les hôtels et guest-h pour les maisons d'hôtes" ). Vous pouvez constater que ce mécanisme est similaire à ce qui se passe dans de nombreuses applications de base de données, mais qu'il est différent du fonctionnement des navigateurs.

Il est important de suivre le principe HATEOAS car il permet aux applications de se développer sans que les applications réceptrices subissent des changements radicaux. Supposons que vous vouliez changer vos URIs de http://example.com/hotel/0928374 a https://reviews.example.com/accommodation/0928374 . Si vous suiviez HATEOAS c'est un simple changement : modifier les valeurs retournées et c'est tout : les applications réceptrices continueront à fonctionner sans aucune modification. Si, au contraire, vous aviez une documentation séparée sur la façon de construire les URI, vous devriez contacter tous les développeurs d'applications et leur demander de remarquer que la documentation a été mise à jour et qu'ils devraient modifier leur code pour refléter les changements.

Avertissement : il s'agit d'une réponse rapide qui ne fait qu'effleurer la surface du problème. Mais si vous avez compris cela, vous avez compris 80% du principe d'HATEOAS.

Answer 3

Cet article m'a aidé à le comprendre en profondeur. http://restcookbook.com/Basics/hateoas/

Il est simple et élégant.

HATEOAS signifie L'hypertexte comme moteur de l'état des applications . Cela signifie qu'il faut utiliser l'hypertexte pour trouver son chemin dans l'API. Un exemple :

GET /account/12345 HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0"?>
<account>
    <account_number>12345</account_number>
    <balance currency="usd">100.00</balance>
    <link rel="deposit" href="http://stackoverflow.com/account/12345/deposit" />
    <link rel="withdraw" href="http://stackoverflow.com/account/12345/withdraw" />
    <link rel="transfer" href="http://stackoverflow.com/account/12345/transfer" />
    <link rel="close" href="http://stackoverflow.com/account/12345/close" />
</account>

Outre le fait que nous avons 100 dollars (US) sur notre compte, nous pouvons voir 4 options : déposer plus d'argent, retirer de l'argent, transférer de l'argent vers un autre compte, ou fermer notre compte. Les balises "link" nous permettent de trouver les URL nécessaires pour les actions spécifiées. Supposons maintenant que nous n'ayons pas 100 USD en banque, mais que nous soyons dans le rouge :

GET /account/12345 HTTP/1.1

HTTP/1.1 200 OK
<?xml version="1.0"?>
<account>
    <account_number>12345</account_number>
    <balance currency="usd">-25.00</balance>
    <link rel="deposit" href="http://stackoverflow.com/account/12345/deposit" />
</account>

Maintenant, nous sommes 25 dollars dans le rouge. Voyez-vous qu'en ce moment nous avons perdu beaucoup de nos options, et que seul le dépôt d'argent est valable ? Tant que nous sommes dans le rouge, nous ne pouvons pas fermer notre compte, ni transférer ou retirer de l'argent du compte. L'hypertexte nous indique en fait ce qui est autorisé et ce qui ne l'est pas : HATEOAS

Answer 4

L'un des problèmes de REST & HATEOAS est la difficulté et le manque de visibilité et de contrôle sur la définition de l'interface. Avec une interaction plus traditionnelle de type RPC, il existe généralement un artefact tel qu'un IDL ou un WSDL qui définit l'API et qui peut être contrôlé et géré par le projet.

Avec un HATEOAS, l'API est dynamiquement descriptible et peut être décrite comme un ensemble de comportements (changements d'état). Les comportements sont décrits dans le code. La description de l'API (WADL) est générée à partir du code plutôt que le code soit généré à partir de la description de l'interface.

Answer 5

Il s'agit d'une excellente vidéo expliquant la contrainte hypermédia de REST.

http://oredev.org/2010/sessions/hypermedia-apis