Quel est le problème avec HATEOAS du côté client?

Si je comprends bien, HATEOAS consiste essentiellement à envoyer avec chaque réponse des liens contenant des informations sur la prochaine étape. 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 requête 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, des liens indiquent 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 ne puissions que déposer. Tout va bien, si nous utilisons Fiddler ou si nous effectuons des requêtes avec le navigateur, nous pouvons facilement voir ce qui peut être fait. Ce type d’information nous est utile pour découvrir les capacités de l’API et le serveur est découplé du client.

Le problème, toutefois, est que lorsque nous construisons un client, comme un SPA avec Javascript, une application Android ou bien d’autres choses, je ne vois pas en quoi HATEOAS continue d’être pertinent. Ce que je veux dire, c’est 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 de recevoir et ce qu'ils rendent pour pouvoir écrire les appels ajax sur le serveur et même pour construire l'interface utilisateur. Lorsque je construis l'interface utilisateur, je dois savoir qu'après avoir demandé le compte, on peut par exemple y déposer, sinon je ne pourrai pas fournir cette option sur l'interface utilisateur. De plus, je devrai connaître l'URI pour effectuer le dépôt afin de 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 les découvrir et de les utiliser, mais lorsque nous construisons un client, l’application que nous construisons ne se contente pas de regarder les liens, puis de se rendre la bonne interface utilisateur et faire les bons appels ajax.

Alors, en quoi HATEOAS est-il important pour les clients? Pourquoi nous ennuyons-nous avec HATEOAS de toute façon?

l'application que nous construisons ne se contente pas de regarder les liens, puis de restituer l'interface utilisateur correcte et d'effectuer les appels ajax appropriés

En fait, c'est exactement ce que HATEOAS va donner l'interface utilisateur. Pas ce qui est possible, mais quand c'est possible. Un HATEOAS formel comme HAL , comme le dit la question, fournit des liens qui indiquent ce qui est possible. Mais lorsque ces liens apparaissent, cela dépend de l'état de l'application. Ainsi, les liens peuvent changer sur la ressource avec le temps (en fonction des actions déjà effectuées).

Cela nous permet de construire une interface utilisateur contenant tous les états possibles , sans vous préoccuper du moment où ces états deviennent actifs. Par exemple, la présence de la rel="deposit"peut indiquer directement à l’UI que le rendu du make depositformulaire est correct . Ce qui permet ensuite à l'utilisateur d'entrer une valeur et de soumettre en utilisant le lien.

Si je comprends bien, HATEOAS consiste essentiellement à envoyer avec chaque réponse des liens contenant des informations sur ce qu'il faut faire ensuite.

HATEOAS est beaucoup plus que de simples liens. C'est "hyper media" en tant que 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 media passé entre le client et le serveur.

Le HTML est un exemple d'hyper media et un exemple de la raison pour laquelle HATEOS fonctionne. La page HTML elle-même est le moteur qui permet au client (c.-à-d. L'utilisateur) de se déplacer sur le site. Un navigateur avec juste la possibilité de rendre HTML présente à l'utilisateur un site Web entièrement navigable. Ce n'est pas simplement qu'il passe 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 permette au navigateur de créer un site navigable.

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

Ceci est valable même si "l'utilisateur" est un autre programme informatique. L'hyper media lui-même devrait définir le contexte de la navigation.

Vous n'avez pas à créer une interface générée dynamiquement. Bien que cela puisse être agréable, ce n'est pas nécessaire. Si vous ne pouvez pas construire une interface dynamique, utilisez simplement les liens et vous avez terminé. L’inconvénient est que vous êtes à nouveau fortement lié au serveur et que vous allez tomber en panne si quelque chose change.

Utiliser la mise en page dynamique peut être assez simple d'ailleurs:

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.