El modelo propuesto por Leonard Richardson ayuda a entender mejor el concepto de REST y a tratar de implementarlo de la mejor forma.

Casi que todo se resume en un diagrama (no en aras de sobresimplificar la importancia de un modelo maduro para REST).

Antes de empezar:

REST (Representational State Transfer) o Transferencia de Estado Representacional.

Básicamente podemos introducir REST –a grandes rasgos- como el modelo de comunicación por HTTP que no utiliza ningún tipo de patrón como SOAP. ¿Cuales fundamentos podemos identificar de REST?

Stateless o sin estado. Se refiere a que cada mensaje que viaja a través de HTTP lleva toda la información necesaria para realizar una petición, es decir, que el servidor no guarda datos referentes a otras comunicaciones con el cliente.

Utilizar las operaciones o verbos ya definidos por HTTP: POST, GET, PUT y DELETE.

Se busca la utilización de URI (Identificador uniforme de recursos), busca identificar de manera precisa un recurso a través de red. Por ejemplo se busca que al llamar a través de una solicitud GET a la dirección “http://www.misitio.com/personas/1” me retorne solamente los datos de la persona con el id número 1 de la colección de personas. De esta forma se busca que los recursos solamente puedan ser direccionables a través de su propia URI.

Utilizar hipermedios, el concepto básicamente es que los resultados de los llamados a un sistema basado en REST permitan navegar a otros recursos sin necesidad de hacer alguna transformación extra. Ejemplo: uso de HTML como retorno.

Ahora sí, teniendo claro que es REST y sus fundamentos veamos el diagrama de madurez propuesto por Richardson:

Consiste de las siguientes partes:

Nivel 0 – Swamp of POX: Se refiere a usar HTTP para interacciones remotas pero sin usar otros mecanismos existentes para web. Nivel 1 – Recursos: La idea es identificar los recursos a través de un URI sin especificar la acción a realizar sobre el mismo. Ejemplo: La URI “http://www.misitio.com/personas/1” representa a una persona y “http://www.misitio.com/personas/2” representa a otra persona.



En lugar de “http://www.misitio.com/personas?id:1” Nivel 2 – Verbos HTTP: Este nivel nos indica que el API debería utilizar los verbos HTTP, mencionados anteriormente. Utilizando correctamente los verbos y las respuestas. Ejemplo: GET http://www.misitio.com/personas/1 DELETE http://www.misitio.com/personas/1 POST http://www.misitio.com/personas/1 PUT http://www.misitio.com/personas/1



Evitando por ejemplo que si ocurre un error lo que se retorne sea un OK (200) que representa una solicitud correcta, sin errores. Nivel 3 – Controles de hypermedia: Básicamente es utilizar HATEOAS (Hipertexto como el mecanismo del estado de la aplicación). Lo que indica HATEOAS es que al realizar un request, el mismo nos retorne información de como trabajar o manipular el recurso. Ejemplo: Si solicitamos datos de una persona “http://www.misitio.com/personas/1” a través de un Middleware intermediario podemos determinar que permisos tiene la persona y que acciones puede realizar y así retornarlas. Aquí es donde entra HATEOAS para retornarnos acceso a diversas funcionalidades para el elemento, ya sea a través de HTML o XML/JSON. GET http://www.misitio.com/personas/1 Resultado en JSON:

{

“nombre”: “Walter”,

”apellido”: “Montes”,

”href”: “http://www.misitio.com/personas/1”

} Con la referencia a la persona junto con la respuesta. Así cuando necesitemos realizar otra acción podemos utilizar los datos de URI del recurso.



Al cumplir con todos los niveles podemso decir que nuestros REST cumplen el nivel de madurez óptimo.

Espero este artículo haya sido de su agrado!

Saludos.