web-dev-qa-db-fra.com

Quel est l'intérêt de HATEOAS côté client?

Si je comprends bien, HATEOAS consiste essentiellement à envoyer avec chaque réponse des liens avec des informations sur la suite des choses. Un exemple simple se trouve facilement sur Internet: un système bancaire associé à une ressource de compte. L'exemple montre cette réponse après une demande GET à une ressource de compte

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="/account/12345/deposit" /> 
    <link rel="withdraw" href="/account/12345/withdraw" /> 
    <link rel="transfer" href="/account/12345/transfer" /> 
    <link rel="close" href="/account/12345/close" /> 
</account>

Avec les données, il existe des liens indiquant ce qui peut être fait ensuite. Si le solde est négatif, nous avons

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="/account/12345/deposit" /> 
</account>

Pour que nous puissions seulement déposer. C'est très bien, si nous utilisons Fiddler ou faisons des demandes avec le navigateur, nous pouvons facilement voir ce qui peut être fait. Ce type d'informations nous est alors utile pour découvrir les capacités de l'API et le serveur est découplé du client.

Cependant, le fait est que lorsque nous créons un client, comme un SPA avec Javascript, ou une application Android ou bien d'autres choses, je ne vois pas comment HATEOAS continue d'être pertinent. signifie ce qui suit: lorsque je code le SPA en javascript, je dois savoir ce qui peut être fait dans l'API pour écrire le code.

J'ai donc besoin de connaître les ressources, les méthodes prises en charge, ce qu'ils s'attendent à recevoir et ce qu'ils donnent en retour afin d'écrire les appels ajax vers le serveur et même afin de construire l'interface utilisateur. Lorsque je crée l'interface utilisateur, je dois savoir qu'après avoir demandé le compte, on peut par exemple déposer sur celui-ci, sinon je ne pourrai pas proposer cette option sur l'interface utilisateur. De plus, je devrai connaître l'URI pour effectuer le dépôt pour construire l'appel ajax.

Ce que je veux dire, c'est que lorsque nous faisons des demandes à l'API, les liens nous permettent de mieux découvrir et utiliser l'API, mais lorsque nous construisons un client, l'application que nous construisons ne se contentera pas de regarder les liens et de se rendre l'interface utilisateur correcte et passer les bons appels ajax.

Alors, comment HATEOAS est-il important pour les clients? Pourquoi nous embêtons-nous de toute façon avec HATEOAS?

restclient-serverhateoas
35
user1620696

l'application que nous construisons ne regardera pas simplement les liens, puis rendra seule l'interface utilisateur correcte et effectuera les bons appels ajax

En fait, c'est exactement ce que HATEOAS donnera l'interface utilisateur. Non ce qui est possible, mais quand c'est possible. Un HATEOAS formel comme HAL , comme l'indique la question, donne des liens qui indiquent ce qui est possible. Mais lorsque ces liens apparaissent dépend de l'état de l'application. Ainsi, les liens peuvent changer sur la ressource au fil du temps (en fonction des actions qui ont déjà été effectuées).

Cela nous permet de construire une interface utilisateur qui contient tous les états possibles , mais sans se préoccuper de lorsque ces états deviennent actifs. Par exemple, la présence de rel="deposit" peut indiquer directement à l'interface utilisateur quand il est OK de rendre le make deposit forme. Ce qui permet ensuite à l'utilisateur de saisir une valeur et de la soumettre à l'aide du lien.

24
Davin Tryon

Si je comprends bien, HATEOAS consiste essentiellement à envoyer avec chaque réponse des liens avec des informations sur la suite des événements.

HATEOAS est bien plus que de simples liens. C'est "hyper media" comme moteur de l'état de l'application.

Ce qui manque dans votre description, c'est le type de contenu, la définition formelle de l'hyper média qui est transmis entre le client et le serveur.

HTML est un exemple d'hyper média et un exemple de la raison pour laquelle HATEOS fonctionne. La page HTML elle-même est le moteur qui permet au client (c'est-à-dire à l'utilisateur) de se déplacer sur le site. Un navigateur avec juste la possibilité de rendre HTML présent à l'utilisateur un site Web entièrement navigable. Ce n'est pas simplement qu'il transmet des liens vers les autres pages, mais il les transmet d'une manière significative qui donne un contexte aux liens et d'une manière qui permet au navigateur de construire un site navigable.

Et plus important encore, le navigateur peut le faire avec une compréhension immédiate du site Web lui-même. Le navigateur ne connaît que HTTP et HTML. Sur la base de cette simple compréhension, il peut présenter le New York Times à l'utilisateur pour naviguer.

Cela est valable même si "l'utilisateur" est un autre programme informatique. L'hyper média lui-même doit définir le contexte de navigation.

3
Cormac Mulhall

Vous n'avez pas besoin de créer une interface générée dynamiquement. Bien que cela puisse être agréable, ce n'est pas obligatoire. Si vous ne pouvez pas créer une interface dynamique, utilisez simplement les liens et vous avez terminé. L'inconvénient est que vous êtes à nouveau fortement lié au backend et que vous planterez si quelque chose change.

L'utilisation de la disposition dynamique peut être assez simple:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

    case 'withdraw':
      loadWithdrawForm(link.href);
      showWithdrawButton();
      break;
  }

});

Il vous enregistre dans votre code client comme:

if (balance <= 0 && negativeBalanceAllowed === false) {
  showWithdrawButton();
}

Vous pouvez mettre en place une position négative autorisée (en empruntant de l'argent par exemple) sans changer de client.

2
Luc Franken