La tra­n­s­fe­re­n­cia de estado re­pre­se­n­ta­cio­nal, más conocida por REST (siglas del inglés Re­pre­se­n­ta­tio­nal State Transfer), forma parte de los pa­ra­di­g­mas de pro­gra­ma­ción más im­po­r­ta­n­tes en el de­sa­rro­llo de apli­ca­cio­nes. Este principio de ar­qui­te­c­tu­ra, pre­se­n­ta­do en el año 2000 por Roy Fielding en su di­se­r­ta­ción, tiene como objetivo principal adaptar las apli­ca­cio­nes web lo mejor posible a los re­qui­si­tos de la Web moderna y, como re­cie­n­te­me­n­te ha ganado en po­pu­la­ri­dad y re­le­va­n­cia, cada vez son más los we­b­ma­s­te­rs que se esfuerzan en aplicar este concepto. Los re­su­l­ta­dos de este esfuerzo, sin embargo, no son siempre realmente REST (RESTful), porque a menudo ciertos pri­n­ci­pios o pro­pie­da­des como HATEOAS no se im­ple­me­n­tan co­rre­c­ta­me­n­te.

¿Qué significa HATEOAS?

El término HATEOAS, in­tro­du­ci­do por Fielding en su de­fi­ni­ción de REST, es el acrónimo de Hypermedia as the engine of appli­ca­cion state (en ca­s­te­llano, hi­pe­r­me­dia como el motor del estado de la apli­ca­ción) y describe una de las pro­pie­da­des más si­g­ni­fi­ca­ti­vas de REST: como este enfoque de diseño de apli­ca­cio­nes ha de ofrecer una interfaz universal, lo que postula HATEOAS es que el cliente pueda moverse por la apli­ca­ción web úni­ca­me­n­te siguiendo a los ide­n­ti­fi­ca­do­res únicos URI en formato hi­pe­r­me­dia. Cuando se aplica este principio, el cliente, aparte de una co­m­pre­n­sión básica de los hi­pe­r­me­dia, no necesita más in­fo­r­ma­ción para poder in­ter­ac­tuar con la apli­ca­ción y el servidor.

Estos URI pueden pre­se­n­tar­se:

  • En forma de atributos href y src si hacen re­fe­re­n­cia a do­cu­me­n­tos HTML o a snippets,
  • Con elementos o atributos JSON o XML que los clientes pueden reconocer de forma au­to­má­ti­ca

La apli­ca­ción del principio HATEOAS permite que la interfaz de un servicio REST pueda mo­di­fi­car­se siempre que se requiera, lo que co­n­s­ti­tu­ye una ventaja fu­n­da­me­n­tal de esta ar­qui­te­c­tu­ra frente a otras, como las basadas en SOAP (Simple Object Access Protocol).

HATEOAS y REST: el paradigma hi­pe­r­me­dia

Para co­m­pre­n­der el si­g­ni­fi­ca­do de HATEOAS para las apli­ca­cio­nes REST, puede ayudar entender primero el marco general. Tal como Fielding define su concepto, son 5 los pri­n­ci­pios fu­n­da­me­n­ta­les que ha de cumplir un servicio para que sea co­n­si­de­ra­do REST.

IvHMM0huDZk.jpg Para mostrar este video, se requieren cookies de terceros. Puede acceder y cambiar sus ajustes de cookies aquí.

En primer lugar, ha de basarse siempre en una es­tru­c­tu­ra cliente-servidor que permita la co­mu­ni­ca­ción sin estado entre el servidor y los clientes, lo que significa que todas las pe­ti­cio­nes de los clientes al servidor se tratan de forma in­de­pe­n­die­n­te a pe­ti­cio­nes an­te­rio­res. El servicio debe estar es­tru­c­tu­ra­do en capas y utilizar las ventajas del caching HTTP (al­ma­ce­na­mie­n­to en caché) para que la uti­li­za­ción del servicio sea lo más sencilla posible para el cliente que realiza la petición. Por último, ha de tener una interfaz unitaria.

Para la conexión entre el servidor y el cliente Fielding define estas cuatro ca­ra­c­te­rí­s­ti­cas:

  • Ide­n­ti­fi­ca­ción ine­quí­vo­ca de todos los recursos: todos los recursos han de poder ide­n­ti­fi­car­se con un URI (Unique Resource Ide­n­ti­fier).
  • In­ter­ac­ción con los recursos por medio de re­pre­se­n­ta­cio­nes: si un cliente necesita un recurso, el servidor le envía una re­pre­se­n­ta­ción (p. ej., HTML, JSON o XML) para que el cliente pueda modificar o borrar el recurso original.
  • Mensajes ex­plí­ci­tos: cada mensaje in­te­r­ca­m­bia­do por el servidor y el cliente ha de contener todos los datos ne­ce­sa­rios para en­te­n­de­r­se.
  • HATEOAS: este principio también integra una API REST. Esta es­tru­c­tu­ra basada en hi­pe­r­me­dia facilita a los clientes el acceso a la apli­ca­ción, puesto que de este modo no necesitan saber nada más de la interfaz para poder acceder y navegar por ella.

HATEOAS es, en de­fi­ni­ti­va, una de las pro­pie­da­des más ele­me­n­ta­les de las API REST y como tal, im­pre­s­ci­n­di­ble en cualquier servicio REST.

Consejo

Si quieres saber más sobre REST consulta nuestro artículo base en la Digital Guide.

HATEOAS aplicado a una tienda online

Para hacer más co­m­pre­n­si­ble el concepto HATEOAS, acla­ra­re­mos a co­n­ti­nua­ción cómo se lleva a la práctica con el ejemplo de una tienda online. Veremos cómo HATEOAS se realiza por medio de hi­pe­re­n­la­ces, como es habitual en el diseño de apli­ca­cio­nes web. Estos enlaces, entre dos do­cu­me­n­tos o a otro punto dentro del mismo documento, se marcan en HTML de esta forma:

<a href="URI">Texto</a>

Los medios (texto, gráficos, audio, video) enlazados de esta forma se denominan hy­pe­r­me­dia. En el caso de las apli­ca­cio­nes web suele tratarse de do­cu­me­n­tos de texto simples en formato HTML, que en este contexto también se entienden como los diversos “estados” (del inglés “states”) de una apli­ca­ción. Dentro de la filosofía REST, cada uno de estos do­cu­me­n­tos tiene un ide­n­ti­fi­ca­dor único URI que permite la co­mu­ni­ca­ción con ellos. Si aplicamos este concepto a una tienda online, este es el resultado:

Al documento que describe el estado “carrito de la compra” se le ha asignado un URI fijo (como, p. ej., 'https://ejemplo.es/ca­rri­to­de­la­co­m­pra'). Los URI para cada uno de los artículos que pueden de­po­si­tar­se en la cesta de la compra siguen el mismo esquema ('https://ejemplo.es/articulo/1'), 'https://ejemplo.es/articulo/2', etc.). Otro posible estado es la “cuenta de usuario”, a la que puede accederse desde el carrito de la compra y que podría tener este URI: 'https://ejemplo.es/cliente/1'. A su vez, cada uno de estos do­cu­me­n­tos/estados contiene los hi­pe­re­n­la­ces a las acciones que el usuario podría llevar a cabo a co­n­ti­nua­ción.

Para el documento de la cesta de la compra esto significa que ha de contener enlaces a los URI de los artículos y los clientes; estos por su parte, a los fa­bri­ca­n­tes o a los contratos. El cliente navega de este modo por la tienda o por el carrito de la compra gracias a los diversos hi­pe­re­n­la­ces vía GET request, como se ve en el siguiente gráfico:

Imagen: HATEOAS aplicado a una tienda online
Re­pre­se­n­ta­ción es­que­má­ti­ca de la apli­ca­ción de HATEOAS en una tienda online

En un servicio REST que siga el principio HATEOAS tal y como lo definió Fielding el usuario solo ha de conocer el URI inicial para poder in­ter­ac­tuar con la oferta según el plan del de­sa­rro­lla­dor.

Apli­ca­cio­nes HATEOAS-REST: ejemplo para la co­mu­ni­ca­ción servidor-cliente

Esta es­tru­c­tu­ra sirve también para explicar cómo tiene lugar la co­mu­ni­ca­ción entre el cliente y el servidor. Con el siguiente código la apli­ca­ción cliente hace una petición para obtener una re­pre­se­n­ta­ción XML del estado “carrito de la compra”:

GET https://ejemplo.es/carritodelacompra HTTP/1.1
Host: https://ejemplo.es
Accept: application/xml

El servidor podría responder entonces:

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: 256
<?xml version="1.0"?>
<carritodelacompra>
    <carritodelacompra_numero>1</carritodelacompra_numero>
    <link rel="cuenta" href="https://ejemplo.es/cliente/1" />
    <link rel="articulo1" href="https://ejemplo.es/articulo/1" />
    <link rel="articulo2" href="https://ejemplo.es/articulo/2" />
</carritodelacompra>
Ir al menú principal