Entendiendo el principio HATEOAS

HATEOAS es la abreviación de Hypermedia as the Engine of Application State (hipermedia como motor del estado de la aplicación). Es una restricción de la arquitectura de la aplicación REST que lo distingue de la mayoría de otras arquitecturas. El principio es que un cliente interactúa con una aplicación de red completamente a través de hipermedia proporcionadas dinámicamente por los servidores de aplicaciones. Es como que el cliente REST debe ir navegando por la información y no necesita ningún conocimiento previo acerca de la forma de interactuar con cualquier aplicación o servidor más allá de una comprensión genérica de hipermedia.

En otras palabras cuando el servidor nos devuelva la representación de un recurso parte de la información devuelta serán identificadores únicos en forma de hipervínculos a otros recursos asociados.

Lo vamos a entender mejor con un ejemplo, supongamos que tenemos una API REST, con cliente y sus diferentes pedidos. El modelo podría ser un cliente que tenga una lista de pedidos.

Lo que podríamos hacer es cuando el cliente REST solicite un cliente por la URI:

myURL/cliente/:id

Devolvemos los datos del cliente con su lista de pedidos. Pero el problema yace en que tal vez tenga muchos pedidos y a la vez el cliente REST necesita datos del cliente no de los pedidos. Por lo tanto, estoy mostrando más información de lo que debiera.

Una solución sería tener otro servicio REST que me devuelva los pedidos, por ejemplo:

myURI/cliente/2

Esta URI me devolverá los datos del cliente 2 que podría ser:

{ id:2, nombre:”Pepe”, apellido:”Gomez” }

Y podríamos hacer otro servicio que nos devuelva los pedidos por medio de la URI:

myURI/cliente/2/pedidos

Supongamos que por algún problema debemos cambiar la URI de pedidos, para hacer esto  debemos avisar a todos los clientes y ellos deberán consumir la nueva URI.

HATEOAS nos dice que debemos mostrar las URIs de forma que el cliente este menos acoplado al servidor y no sea necesario hacer cambios en estos casos.

Por ejemplo el servicio de consulta de clientes puede devolver la URI del pedido de la siguiente manera:

{ id:2, nombre:”Pepe”, apellido:”Gomez” , pedidos:”myURL/cliente/2/pedidos ”}

A la vez si no mostramos la URI de los pedidos el cliente REST tiene que ir a la documentación de la API por cada servicio que desee utilizar. Con HATEOAS los servicios descubren nuevos servicios lo que permite navegar por la información y un cliente que una URI principal puede ir descubriendo los demás servicios.  

La restricción HATEOAS desacopla cliente y el servidor de una manera que permite la funcionalidad del servidor para evolucionar de forma independiente.

Dejo link: http://en.wikipedia.org/wiki/HATEOAS