RESTRepresentational State Transfer

OpenWebinarsCurso de front-end (2014)

Sergio Rus@sergiorus

REST no es una tecnología ni un protocolo. Es simplemente un estilo de arquitectura de red. La WWW (Web) que tenemos actualmente es un ejemplo de arquitectura REST.

¿Qué es REST?

REST se suele asociar al protocolo HTTP, aunque en realidad los principios enunciados en REST son válidos para cualquier protocolo de comunicación de red. A pesar de esto, REST es un compendio de ideas reunidas por las mismas personas que diseñaron HTTP 1.1. Por ello, algunas de estas ideas ya las conocemos de este protocolo.

¿Qué es REST?

Siguiendo los principios o restricciones propuestos en REST es posible obtener una arquitectura de red óptima en el sentido de que maximiza propiedades como:

● Rendimiento● Escalabilidad● Simplicidad● Portabilidad● Fiabilidad

¿Qué es REST?

● Modelo cliente-servidor● Protocolo de comunicación stateless● Uso de caché● Elementos de red organizados por capas● Interfaz uniforme entre cliente y servidor● Client-side scripting (opcional)

Principios de REST

http://slides.com/onema/http-protocol

HTTP request

HTTP request

HTTP request HTTP response

HTTP response

Cliente-servidor

Stateless

El cliente es siempre el que comienza la comunicación con el servidor. Además todas las peticiones (requests) del cliente son independientes: no se guardan datos (estado) entre una petición y otra, es decir, el servidor debe tratar cada petición de forma independiente. No existe el concepto “estado de la sesión” en el servidor. El cliente es el único que debe gestionar el estado de la sesión.

Uso de caché

Siempre que sea posible, las respuestas del servidor deben ser cacheadas, tanto en el cliente como en los elementos intermedios de red. Esto mejora el rendimiento y la escalabilidad de la arquitectura de red.

Por ejemplo, en HTTP es muy importante tratar de usar siempre cabeceras para cachear las respuestas.

Organización por capas

Entre el cliente y el servidor puede existir un número indeterminado de elementos de red (proxies, routers, cachés, servidores, etc) que deben actuar de forma transparente en la comunicación cliente-servidor, ayudando además a mejorar el rendimiento, la escalabilidad y la seguridad.

Interfaz uniforme

Es imprescindible que no exista acoplamiento entre el cliente y el servidor. El cliente sólo debe conocer la URI (URL o URN) del recurso al que accede en el servidor. Esta URI identifica cada recurso de forma unívoca y permanente. Además debe ocultar detalles de implementación, como el tipo de representación (XML, JSON, etc).

Interfaz uniforme

Un recurso es un concepto abstracto, luego no necesariamente equivale directamente a datos almacenados en el servidor. El cliente manipula los recursos del servidor mediante representaciones, que pueden ser en cualquier formato (HTML, XML, JSON, JPG, PNG, MP3, etc).

Interfaz uniforme

El cliente debe ser capaz de manipular los recursos del servidor únicamente a partir de la información contenida en las respuestas del servidor y en lasrepresentaciones de recursos que devuelve éste.La única información previa que podría conocer el cliente es la URI de entrada al servidor, es decir, la ruta principal (/). Cualquier otra URI para acceder a un recurso debe poder ser descubierta a partir de links.

RESTful

Si una aplicación o servicio web cumple todos estos requisitos entonces se dice que es RESTful.

RESTful

Por ejemplo: no podemos hablar de que una API es RESTful si las representaciones de recursos que devuelve no contienen links, o bien, las URIs que utilizan para identificar recursos no son unívocas.

RESTful

La mayoría de APIs que se autodenominan RESTful en realidad no lo son. Ejemplo: Stripe.

Referencias

● Roy Thomas Fielding - artículo original sobre REST

● Roy Thomas Fielding - artículo de opinión sobre la palabra de moda: RESTful

● REST book - un resumen de buenas prácticas● Cómo diseñar URLs RESTful● Cómo versionar APIs según REST