Frontend leccion

1. REST
Representational State Transfer
OpenWebinars
Curso de front-end (2014)
Sergio Rus
@sergiorus

2. 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?

3. 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?

4. 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?

5. ● 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

6. http://slides.com/onema/http-protocol
HTTP request
HTTP request
HTTP request
HTTP response
HTTP response
Cliente-servidor

7. 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.

8. 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.

9. 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.

10. 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).

11. 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).

12. 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 las
representaciones 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.

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

14. 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.

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

16. 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