¿Cuál es el punto con HATEOAS en el lado del cliente?

Como entiendo actualmente, HATEOAS se trata básicamente de enviar junto con cada respuesta enlaces con información sobre qué hacer a continuación. Un ejemplo simple se encuentra fácilmente en Internet: un sistema bancario junto con un recurso de cuenta. El ejemplo muestra esta respuesta después de una solicitud GET a un recurso de cuenta

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>

Junto con los datos, hay enlaces que indican qué se puede hacer a continuación. Si el saldo es negativo tenemos

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 solo podamos depositar. Eso está bien, si estamos usando Fiddler o haciendo solicitudes con el navegador, podemos ver fácilmente qué se puede hacer. Este tipo de información es útil para que descubramos las capacidades de la API y el servidor se desacople del cliente.

El punto, sin embargo, es que cuando creamos un cliente, como un SPA con Javascript, o una aplicación de Android o muchas otras cosas, no puedo ver cómo HATEOAS sigue siendo relevante. Lo que quiero decir es lo siguiente: cuando estoy codificando el SPA en JavaScript, debo saber qué se puede hacer en la API para escribir el código.

Por lo tanto, necesito conocer los recursos, los métodos admitidos, lo que esperan recibir y lo que devuelven para escribir las llamadas ajax en el servidor e incluso para construir la interfaz de usuario. Cuando construyo la IU, debo saber que después de solicitar la cuenta, uno puede, por ejemplo, depositar en ella, o no podré proporcionar esta opción en la IU. Además, necesitaré conocer el URI para hacer el depósito para construir la llamada ajax.

Lo que quiero decir es que, cuando hacemos solicitudes a la API, los enlaces nos permiten descubrir y usar la API mejor, pero cuando creamos un cliente, la aplicación que estamos construyendo no solo mirará los enlaces y luego se renderizará la interfaz de usuario correcta y hacer las llamadas correctas ajax.

Entonces, ¿cómo es importante HATEOAS para los clientes? ¿Por qué nos molestamos con HATEOAS de todos modos?

la aplicación que estamos construyendo no solo mirará los enlaces y, por sí sola, representará la IU correcta y realizará las llamadas ajax correctas

De hecho, esto es exactamente lo que HATEOAS le dará a la interfaz de usuario. No es lo que es posible, sino cuándo es posible. Un HATEOAS formal como HAL , como dice la pregunta, proporciona enlaces que indican lo que es posible. Pero cuando aparecen esos enlaces depende del estado de la aplicación. Por lo tanto, los enlaces pueden cambiar en el recurso con el tiempo (en función de las acciones que ya se han realizado).

Esto nos permite construir una interfaz de usuario que contenga todos los estados posibles , pero no nos preocupemos cuando esos estados se activen. Por ejemplo, la presencia de rel="deposit"puede indicar directamente a la interfaz de usuario cuándo está bien procesar el make depositformulario. Lo que luego le permite al usuario ingresar un valor y enviarlo usando el enlace.

Como entiendo actualmente, HATEOAS se trata básicamente de enviar junto con cada respuesta enlaces con información sobre qué hacer a continuación

HATEOAS es mucho más que solo enlaces. Es "hipermedia" como motor del estado de la aplicación.

Lo que se pierde en su descripción es el tipo de contenido, la definición formal del hipermedio que se pasa entre el cliente y el servidor.

HTML es un ejemplo de los medios de comunicación hiper, y un ejemplo de por qué funciona HATEOS. La página HTML en sí es el motor que permite al cliente (es decir, el usuario) se mueva a través del sitio. Un navegador con sólo una capacidad de representar HTML presente al usuario una página web totalmente navegable. No es simplemente que pase enlaces a otras páginas, pero los pasa de una manera significativa que da contexto a los enlaces y de una manera que permite que el navegador para la construcción de un sitio navegable.

Y lo más importante, el navegador puede hacer esto con cero hasta la comprensión frente a la propia página web. El navegador sólo sabe HTTP y HTML. Sobre la base de ese simple comprensión de que puede presentar el New York Times para el usuario a través de navegar.

Esto se aplica incluso si el "usuario" es otro programa de computadora. Los propios medios hiper deben definir el contexto de la navegación.

No tiene que construir una interfaz generada dinámicamente. Aunque podría ser agradable, no es obligatorio. Si no puede construir una interfaz dinámica, simplemente use los enlaces y listo. La desventaja es que nuevamente está vinculado al backend y se bloqueará si algo cambia.

Usar el diseño dinámico puede ser bastante simple por cierto:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

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

});

Te ahorra en tu código de cliente como:

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

Puede implementar una posición negativa permitida (tomando dinero prestado, por ejemplo) sin cambiar su cliente.