rest - specifically - spring hal

HATEOAS: descripción concisa

Question

Estoy tratando de obtener una comprensión clara y concisa de HATEOAS, y de ninguna manera soy un experto RESTO DE WRT. (Creo que lo entiendo, gracias a esto http://www.looah.com/source/view/2284 ).

¿Alguien puede sugerir un blog / artículo igualmente enriquecedor WRT HATEOAS?

Answer 1

Desde mi experiencia personal trabajando con un motor HATEOAS, la mayor diferencia es la filosofía del diseño en sí.

Si vamos a construir una aplicación web, hay dos enfoques para ello. Uno es el Estilo RPC y el otro es el Estilo REST.

Si el estado debe probarse en un estilo RPC, debemos llamar a un procedimiento RPC que devuelva un resultado. Con este enfoque de diseño, los parámetros devueltos después de la primera llamada deben almacenarse en el cliente para que otras llamadas puedan usar los parámetros que se devolvieron. Esto simplemente hace que el cliente y el servidor estén estrechamente conectados, lo que hace que el sistema en general tenga estado.

Mientras que en el estilo REST, no hay RPC. Lo que importa son las interacciones entre el cliente y el servidor. Para cualquier transición de estado, el cliente tiene que interactuar con el servidor para obtener información. La única interacción que se soluciona es la interacción en el hogar. El resto es descubierto por el cliente a medida que atraviesa las diferentes interacciones.

Desde una perspectiva de informática, uno es de estilo de procedimiento y es algorítmico. donde como el estilo REST es un paradigma interaccional. Cualquier sistema que adopte el paradigma de interacción como lenguaje estaría entregando un sistema HATEOAS.

Answer 2

Este artículo me ayudó a entenderlo a fondo. http://restcookbook.com/Basics/hateoas/

Es simple y elegante.

HATEOAS significa Hipertexto como el motor del estado de la aplicación . Significa que el hipertexto debe usarse para encontrar el camino a través de la API. Un ejemplo:

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>

Además del hecho de que tenemos 100 dólares (EE. UU.) En nuestra cuenta, podemos ver 4 opciones: depositar más dinero, retirar dinero, transferir dinero a otra cuenta o cerrar nuestra cuenta. Las etiquetas de "enlace" nos permiten conocer las URL que se necesitan para las acciones especificadas. Ahora, supongamos que no tenemos 100 USD en el banco, pero en realidad estamos en rojo:

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>

Ahora tenemos 25 dólares en números rojos. ¿Ves que en este momento hemos perdido muchas de nuestras opciones, y solo depositar dinero es válido? Mientras que estemos en números rojos, no podemos cerrar nuestra cuenta, ni transferir ni retirar dinero de la cuenta. El hipertexto realmente nos dice lo que está permitido y lo que no: HATEOAS

Answer 3

HATEOAS en pocas palabras: en los datos que genera, consulte otros recursos utilizando URI, no ID.

Como todas las definiciones cortas, la definición que acabo de dar está equivocada en muchos niveles, pero debería hacerle comprender cuál es el quid de HATEOAS.

Ahora, para una explicación un poco más larga.

El principio HATEOAS dice que el estado de su aplicación debe avanzar a través de enlaces de hipertexto. Piensa en que navegas por Internet. Primero debe escribir una dirección en la barra de direcciones. A partir de ese punto, su navegación avanza bastante solo gracias a los clics en los enlaces: hace clic en un enlace y termina en otra página. Otro clic y aquí aparece otra página. ¿Cómo fue el navegador capaz de moverlo de la primera página a la segunda y la tercera? Usó las URL codificadas en los elementos <a> .

Del mismo modo, si sus aplicaciones REST generan este resultado

<accomodation>
<hotel info="http://example/hotel/0928374" price="200"/>
<guest-house info="http://example/guest-h/7082" price="87"/>
</accomodation>

entonces la aplicación receptora no tendrá que acceder a ninguna fuente externa de conocimiento para saber que el primer hotel está disponible en http://example/hotel/0928374 y el segundo en http://example/guest-h/7082 .

Por otro lado, si su aplicación genera respuestas con ID como

<accomodation>
<hotel id="0928374" price="200"/>
<guest-house id="7082" price="87"/>
</accomodation>

la aplicación receptora deberá saber de antemano cómo se deben crear los ID con prefijos para obtener el URI en el que está disponible la información para cada alojamiento (por ejemplo, "agregar http://example/ a cada solicitud, luego agregar el hotel para hoteles y guest-h para casas de huéspedes " ). Puede ver que este mecanismo es similar a lo que sucede en muchas aplicaciones DB, pero es diferente de cómo funcionan los navegadores.

Es importante seguir el principio HATEOAS porque permite que las aplicaciones crezcan sin cambios drásticos en las aplicaciones receptoras. Supongamos que desea cambiar sus URI de http://example.com/hotel/0928374 a https://reviews.example.com/accommodation/0928374 . Si siguió HATEOAS sería un cambio simple: modifique los valores devueltos y que lo sea: las aplicaciones receptoras continuarán funcionando sin ninguna modificación. Si, por el contrario, tuvieras documentación separada sobre cómo construir el URI, deberás contactar a todos los desarrolladores de la aplicación y pedirles que noten que la documentación ha sido actualizada y que deben cambiar su código para reflejar los cambios.

Descargo de responsabilidad: esta es una respuesta rápida que solo araña la superficie del problema. Pero si obtienes esto, tienes el 80% del principio HATEOAS.

Answer 4

La Restricción de Hypermedia (anteriormente conocida como HATEOAS) es una restricción que se utiliza para proporcionar dirección al usuario-agente.

Al incluir enlaces en las representaciones devueltas, el servidor puede eliminar la carga del agente usuario para determinar qué acciones se pueden tomar en función del estado de la aplicación actual y saber con quién interactuar para lograr ese objetivo.

Como el servidor no tiene conocimiento del estado actual del agente de usuario que no sea el que recibe en una solicitud, es importante que el agente de usuario intente evitar el uso de un estado distinto de las representaciones devueltas desde el servidor. Esto garantiza que las acciones disponibles proporcionadas por el servidor se basen en la comprensión más completa posible del estado del agente de usuario.

Un usuario-agente que se ajuste a la restricción Hypermedia actúa como una máquina de estado, donde las transiciones de estado son causadas por los siguientes enlaces disponibles en la representación actual. La representación devuelta se convierte en el nuevo estado.

Los beneficios de este enfoque pueden ser un agente de usuario muy liviano . Requiere muy poco código para administrar el estado, ya que sus acciones deberían basarse únicamente en la respuesta recibida y el enlace que recuperó esa respuesta. El código del agente de usuario se vuelve declarativo y reactivo, en lugar de secuencias imperativas de OBTENER esto, luego haz esto y luego hazlo, simplemente tienes la mecánica para seguir los enlaces y muchas instancias de CUÁNDO recibes esto ENTONCES haz eso.

Para ver un ejemplo de cómo funciona esto, no necesita buscar más allá de su navegador web y un sitio web que no utiliza Javascript. El navegador le presenta opciones basadas en enlaces en el HTML. Cuando sigue ese enlace, el navegador reemplaza su estado actual con el nuevo estado recuperado cuando siguió el enlace. El botón Atrás funciona (o al menos debería) porque está recuperando el estado de un enlace en su historial. Al navegador no le debe importar cómo llegó a la página, ya que el estado debe basarse por completo en la representación recuperada.

Este modelo de "administración estatal" puede ser muy limitante , ya que su estado de aplicación actual se basa en una única respuesta del servidor. Sin embargo, las aplicaciones complejas se pueden construir mediante el uso de un conjunto de agentes de usuario que trabajan en conjunto . Esto es parte de lo que AJAX logra al permitir que un usuario-agente distinto sea utilizado para realizar solicitudes por separado y, por lo tanto, administrar otra máquina de estados. Lamentablemente, la mayoría de las personas recurre a un estilo RPC cuando comienzan a realizar solicitudes de JavaScript, lo que es desafortunado teniendo en cuenta la asincronía natural de Javascript.

Answer 5

Un problema con REST y HATEOAS es la dificultad y la falta de visibilidad y control sobre la definición de la interfaz. Con una interacción de estilo RPC más tradicional, generalmente había un artefacto, como IDL o WSDL, que definía la API y podía ser controlado y gestionado por el proyecto.

Con un HATEOAS, la API es dinámicamente desagradable y se puede describir como un conjunto de comportamientos (cambios de estado). Los comportamientos se describen en el código. La descripción de la API (WADL) se genera a partir del código en lugar del código que se genera a partir de la descripción de la interfaz.