Qual è il punto con HATEOAS sul lato client?

29

Come attualmente capisco, HATEOAS è fondamentalmente basato sull'invio di ogni link di risposta con informazioni su cosa fare dopo. Un semplice esempio è facilmente reperibile su Internet: un sistema bancario insieme a una risorsa account. L'esempio mostra questa risposta dopo una richiesta GET a una risorsa 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 depositare solo. Va bene, se stiamo usando Fiddler o facciamo richieste con il browser, possiamo facilmente vedere cosa si può fare. Questo tipo di informazioni è utile quindi per noi per scoprire le capacità dell'API e il server è disaccoppiato dal client.

Il punto, tuttavia, è che quando costruiamo un client, come una SPA con Javascript, o un'app per Android o molte altre cose, non vedo 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 scrivere le chiamate ajax al server e anche per costruire l'interfaccia utente. Quando creo l'interfaccia utente, devo sapere che, dopo aver richiesto l'account, è possibile, ad esempio, effettuare un deposito in esso oppure non sarei in grado di fornire questa opzione nell'interfaccia utente. Inoltre, dovrò conoscere l'URI per effettuare il deposito per costruire la chiamata ajax.

Quello che voglio dire è che quando facciamo richieste all'API, i collegamenti ci permettono di scoprire e utilizzare meglio l'API, ma quando costruiamo un client, l'app che stiamo costruendo non guarderà semplicemente i link e quindi di per sé rende l'interfaccia utente corretta e fa le giuste chiamate ajax.

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

    
posta user1620696 08.02.2015 - 23:53
fonte

3 risposte

21

the app we are building won't simply look at the links and then by itself render the correct UI and make the right ajax calls

In effetti, questo è esattamente ciò che HATEOAS fornirà all'interfaccia utente. Non ciò che è possibile, ma quando è possibile. Un HATEOAS formale come HAL , come afferma la domanda, fornisce collegamenti che indicano cosa è possibile. Ma quando questi collegamenti vengono visualizzati dipende dallo stato dell'applicazione. Pertanto, i collegamenti possono modificare sulla risorsa nel tempo (in base alle azioni già eseguite).

Questo ci permette di costruire un'interfaccia utente che contenga tutti gli stati possibili , ma non preoccuparti di quando quegli stati diventano attivi. Ad esempio, la presenza di rel="deposit" può dire direttamente all'interfaccia utente quando è OK per il rendering della forma make deposit . Che quindi consente all'utente di inserire un valore e inviare utilizzando il link.

    
risposta data 09.02.2015 - 00:26
fonte
2

As I currently understand HATEOAS is basically all about sending together with each response links with information about what to do next

HATEOAS è molto più che semplici collegamenti. È "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 trasmessa tra client e server.

HTML è un esempio di hyper media e un esempio del perché HATEOS funziona. La stessa pagina HTML è il motore che consente al client (cioè all'utente) di spostarsi attraverso il sito. Un browser con una semplice capacità di rendere HTML presente all'utente un sito web completamente navigabile. Non è semplicemente il fatto che passa i collegamenti alle altre pagine, ma li passa in modo significativo che fornisce un contesto ai collegamenti e in un modo che consente al browser di costruire un sito navigabile.

E, soprattutto, il browser può farlo con ZERO in prima visione del sito stesso. Il browser conosce solo HTTP e HTML. Sulla base di questa semplice comprensione, può presentare il New York Times all'utente per navigare attraverso.

Questo vale anche se l'utente è un altro programma per computer. Lo stesso hyper media dovrebbe definire il contesto di navigazione.

    
risposta data 09.02.2015 - 13:28
fonte
2

Non è necessario creare un'interfaccia generata dinamicamente. Anche se potrebbe essere bello non è richiesto. Se non è possibile creare un'interfaccia dinamica, basta usare i collegamenti e il gioco è fatto. Lo svantaggio è che sei di nuovo molto legato al back-end e si bloccherà se qualcosa cambia.

Utilizzare il layout dinamico può essere abbastanza semplice btw:

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();
}

Puoi implementare una posizione negativa consentita (prendendo in prestito denaro ad esempio) senza cambiare il tuo cliente.

    
risposta data 09.02.2015 - 06:55
fonte

Leggi altre domande sui tag