Qual é o objetivo do HATEOAS no lado do cliente?

Atualmente, como eu entendo, o HATEOAS é basicamente o envio de cada link de resposta com informações sobre o que fazer em seguida. Um exemplo simples é facilmente encontrado na internet: um sistema bancário juntamente com um recurso da conta. O exemplo mostra esta resposta após uma solicitação GET para um recurso de conta

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>

Juntamente com os dados, existem links informando o que pode ser feito a seguir. Se o saldo for negativo, temos

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>

Para que possamos apenas depositar. Tudo bem, se estamos usando o Fiddler ou fazendo solicitações com o navegador, podemos ver facilmente o que pode ser feito. Esse tipo de informação é útil para descobrirmos os recursos da API e o servidor é dissociado do cliente.

O ponto, no entanto, é que, quando construímos um cliente, como um SPA com Javascript, um aplicativo Android ou muitas outras coisas, não consigo ver como o HATEOAS continua sendo relevante. O que quero dizer é o seguinte: quando estou codificando o SPA em javascript, preciso saber o que pode ser feito na API para escrever o código.

Então, eu preciso conhecer os recursos, os métodos suportados, o que eles esperam receber e o que devolvem para gravar as chamadas ajax no servidor e até para criar a interface do usuário. Quando crio a interface do usuário, devo saber que, depois de solicitar a conta, é possível, por exemplo, depositar nela, ou não poderei fornecer essa opção na interface do usuário. Além disso, precisarei conhecer o URI para fazer o depósito e criar a chamada ajax.

O que quero dizer é que, quando fazemos solicitações para a API, os links permitem descobrir e usar melhor a API, mas quando construímos um cliente, o aplicativo que estamos construindo não olha apenas para os links e depois renderiza sozinho a interface do usuário correta e faça as chamadas ajax corretas.

Então, como a HATEOAS é importante para os clientes? Por que nos incomodamos com o HATEOAS?

o aplicativo que estamos construindo não irá simplesmente olhar para os links e, por si só, renderizar a interface do usuário correta e fazer as chamadas ajax corretas

Na verdade, este é exatamente o que HATEOAS vai dar a interface do usuário. Não é o que é possível, mas quando é possível. Um HATEOAS formal como o HAL , como a pergunta indica, fornece links que indicam o que é possível. Mas quando esses links aparecerem, depende do estado do aplicativo. Portanto, os links podem mudar no recurso ao longo do tempo (com base em ações que já foram executadas).

Isso nos permite criar uma interface do usuário que contenha todos os estados possíveis , mas não nos preocupemos quando esses estados se tornarem ativos. Por exemplo, a presença do rel="deposit"pode informar diretamente a interface do usuário quando estiver OK para renderizar o make depositformulário. O que permite ao usuário inserir um valor e enviar usando o link.

Atualmente, como eu entendo, o HATEOAS é basicamente o envio de links de resposta com informações sobre o que fazer a seguir

HATEOAS é muito mais do que apenas links. É "hiper mídia" como o mecanismo do estado do aplicativo.

O que está faltando em sua descrição é o tipo de conteúdo, a definição formal da hiper mídia que é transmitida entre cliente e servidor.

HTML é um exemplo de hipermídia e um exemplo de por que o HATEOS funciona. A própria página HTML é o mecanismo que permite ao cliente (ou seja, o usuário) percorrer o site. Um navegador com apenas a capacidade de tornar o HTML presente para o usuário um site totalmente navegável. Não é apenas o fato de transmitir links para as outras páginas, mas de maneira significativa, contextualizando os links e de maneira a permitir que o navegador construa um site navegável.

E o mais importante é que o navegador pode fazer isso com o ZERO, com uma compreensão antecipada do próprio site. O navegador conhece apenas HTTP e HTML. Com base nesse entendimento simples, ele pode apresentar o New York Times ao usuário para navegar.

Isso ocorre mesmo que o "usuário" seja outro programa de computador. A hiper mídia em si deve definir o contexto da navegação.

Você não precisa criar uma interface gerada dinamicamente. Embora possa ser bom, não é necessário. Se você não pode construir uma interface dinâmica, basta usar os links e pronto. A desvantagem é que você está novamente vinculado ao back-end e travará se algo mudar.

Usar o layout dinâmico pode ser bem simples:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

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

});

Ele economiza seu código de cliente como:

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

Você pode implementar uma posição negativa permitida (emprestando dinheiro, por exemplo) sem alterar seu cliente.