Qual è il punto con HATEOAS sul lato client?

Come capisco attualmente, HATEOAS si basa essenzialmente sull'invio insieme a ciascun link di risposta con informazioni su cosa fare dopo. Un semplice esempio è facilmente reperibile su Internet: un sistema bancario insieme a una risorsa di conto. L'esempio mostra questa risposta dopo una richiesta GET a una risorsa dell'account

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>

Insieme ai dati ci sono collegamenti che dicono cosa si può fare dopo. Se il saldo è negativo, abbiamo

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>

In modo che possiamo solo depositare. Va bene, se stiamo usando Fiddler o stiamo facendo richieste con il browser possiamo facilmente vedere cosa si può fare. Questo tipo di informazioni è utile per noi per scoprire le capacità dell'API e il server viene disaccoppiato dal client.

Il punto, tuttavia, è che quando costruiamo un client, come una SPA con Javascript, o un'app Android o molte altre cose, non riesco a vedere come HATEOAS continui ad essere rilevante. Quello che intendo è il seguente: quando sto codificando la SPA in javascript, devo sapere cosa si può fare nell'API per scrivere il codice.

Quindi ho bisogno di conoscere le risorse, i metodi supportati, cosa si aspettano di ricevere e cosa restituiscono per poter scrivere le chiamate Ajax sul server e persino per costruire l'interfaccia utente. Quando creo l'interfaccia utente, devo sapere che dopo aver richiesto l'account, ad esempio, si può depositare in esso o non sarò in grado di fornire questa opzione sull'interfaccia utente. Inoltre, dovrò conoscere l'URI per effettuare il deposito per creare la chiamata ajax.

Quello che voglio dire è che quando facciamo richieste all'API, i collegamenti ci permettono di scoprire e usare meglio l'API, ma quando costruiamo un client, l'app che stiamo costruendo non guarderà semplicemente i collegamenti e quindi renderà da soli l'interfaccia utente corretta ed effettua le giuste chiamate ajax.

Quindi, quanto è importante HATEOAS per i clienti? Perché ci preoccupiamo comunque di HATEOAS?

l'app che stiamo costruendo non guarderà semplicemente i collegamenti e quindi da sola renderà l'interfaccia utente corretta ed effettuerà le giuste chiamate ajax

In realtà, questo è esattamente ciò che hateoas vi darà l'interfaccia utente. Non è ciò che è possibile, ma quando è possibile. Un HATEOAS formale come HAL , come afferma la domanda, fornisce collegamenti che indicano ciò che è possibile. Ma quando vengono visualizzati quei collegamenti dipende dallo stato dell'applicazione. Pertanto, i collegamenti possono cambiare nel tempo sulla risorsa (in base alle azioni che sono già state eseguite).

Questo ci consente di creare un'interfaccia utente che contenga tutti gli stati possibili , ma non preoccuparci di quando tali stati diventano attivi. Ad esempio, la presenza di rel="deposit"può indicare direttamente all'interfaccia utente quando è corretto eseguire il rendering del make depositmodulo. Che quindi consente all'utente di inserire un valore e inviare utilizzando il collegamento.

Come capisco attualmente, HATEOAS si basa essenzialmente sull'invio insieme a ciascun link di risposta con informazioni su cosa fare dopo

HATEOAS è molto più di un semplice link. È "hyper media" come motore dello stato dell'applicazione.

Ciò che manca nella descrizione è il tipo di contenuto, la definizione formale dell'hyper media che viene passato tra client e server.

HTML è un esempio di hyper media e un esempio del motivo per cui HATEOS funziona. La stessa pagina HTML è il motore che consente al client (ovvero all'utente) di spostarsi nel sito. Un browser con la sola capacità di rendere HTML presente all'utente un sito Web completamente navigabile. Non si limita semplicemente a passare i collegamenti alle altre pagine, ma li passa in un modo significativo che dà contesto ai collegamenti e in un modo che consente al browser di costruire un sito navigabile.

E, soprattutto, il browser può farlo con ZERO a conoscenza del sito Web stesso. Il browser conosce solo HTTP e HTML. Sulla base di questa semplice comprensione, può presentare all'utente il New York Times.

Ciò vale anche se l '"utente" è un altro programma per computer. L'hyper media stesso dovrebbe definire il contesto di navigazione.

Non è necessario creare un'interfaccia generata dinamicamente. Anche se potrebbe essere bello, non è richiesto. Se non riesci a creare un'interfaccia dinamica, usa semplicemente i collegamenti e il gioco è fatto. Lo svantaggio è che sei di nuovo fortemente collegato al backend e andrà in crash se qualcosa cambia.

L'uso del layout dinamico può essere abbastanza semplice tra l'altro:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

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

});

Ti salva nel tuo codice cliente come:

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

È possibile implementare una posizione negativa consentita (prendendo ad esempio denaro in prestito) senza cambiare cliente.