PDF de programación - REST:Representational State Transfer

REST:Representational State Transfer

Escuela Técnica Superior de Ingeniería de Telecomunicación

Universidad Rey Juan Carlos

gsyc-profes (arroba) gsyc.urjc.es

Abril de 2016

GSyC - 2016

REST

1

c2016 GSyC
Algunos derechos reservados.
Este trabajo se distribuye bajo la licencia
Creative Commons Attribution Share-Alike 4.0

GSyC - 2016

REST

2

REST

Introducción a REST

REST Representational State Transfer es la tecnología más
empleada actualmente para intercambiar información de gestión
entre máquina y máquina

En rigor, REST es una propuesta académica, no una
arquitectura concreta.
Define una serie de características que debería cumplir una
arquitectura.
Los protocolos que cumplen las restrucciones REST, se les
denomina RESTful
Desarrollado por Roy Fielding a finales de los años 90. Publica
REST en su tesis doctoral, año 2000

Fielding es uno de los autores de HTTP 1.1

En la práctica, cuando una aplicación dice ser REST, suele ser
ROA (una arquitectura REST concreta desarrollada
L.Richardson y S.Ruby)

GSyC - 2016

REST

3

Características de una arquitectura REST

Introducción a REST

Una arquitectura es REST si cumple estas 6 caracterísitcas

1 Cliente-servidor

2 Sin estado (stateless)

3 Admite el uso de caches (cacheable)

4 Sistema basado en capas (layered system)

5 Generación (opcional) de código bajo demanda

6 Uso de interfaces uniformes

Identificación de recursos
Manipulación de recursos mendiante representaciones
Mensajes autodescriptivos
Hipermedia como motor del estado de la aplicación
(HATEOAS, Hypermedia as the engine of application state)

GSyC - 2016

REST

4

1. Cliente-servidor

Introducción a REST

Clara separación cliente-sevidor en el API, interfaz robusto
que permita desarrollo independiente de cada parte

P.e. El cliente no almacena datos

El servidor ignora al usuario: tanto el interfaz de usuario como
el estado de usuario

Cliente y servidor se pueden desarrollar por separado

GSyC - 2016

REST

5

2. Sin estado

Introducción a REST

En el servidor no se almacena contexto de las peticiones del
cliente

Cada petición del cliente contienen toda la información
necesaria para que el servidor responda

La sesión y el estado del cliente se guardan en el cliente

Todo esto simplifica la lógica del servidor

Garantiza que no llegará a estados inconsistentes (no hay
estado)
Permite replicar los servidores
Facilita el escalado

GSyC - 2016

REST

6

Introducción a REST

Ejemplo de protocolo sin estado:

HTTP

Ejemplo de protocolo que sí tiene estado:

FTP

Hay una sesión, con un usuario autenticado, con directorio de
trabajo, con modo de transferencia (texto o binario)
preestablecido

GSyC - 2016

REST

7

3. Admite cachés

Introducción a REST

Cada respuesta indica si es susceptible de ser almacenada en
un cache o no

Si no lo es, los cachés se deshabilitarán, lo que garantiza que
no se usará información obsoleta o inadecuada

Usar caches mejora escalabilidad y el rendimiento

GSyC - 2016

REST

8

4. Sistema basado en capas

Introducción a REST

Entre cliente y servidor puede haber proxys, caches o gateways, sin
que el cliente lo perciba y sin que produzcan resultados incorrectos

Un proxy es un intermediario. Recibe la petición y la vuelve a
enviar.

Por motivos de seguridad, para poner un filtro para niños, para
conseguir anonimato, para modificar los documentos sobre la
marcha (cambiar formato, idioma..) para forzar a que una red
pase por una máquina y haga cache...

Un gateway es como un proxy, pero cambiando de protocolo.
P.e. gateway http-ftp

GSyC - 2016

REST

9

5. Puede generar código bajo demanda

Introducción a REST

Opcionalmente, el servidor puede ampliar la funcionalidad del
cliente enviando código, como applets java o JavaScript

GSyC - 2016

REST

10

6. Interfaz uniforme

Introducción a REST

Es la característica principal de cualquier sistema REST. Permite
sistemas débilmente acoplados

6.1 Identificación de recursos

6.2 Manipulación de recursos mendiante representaciones

6.3 Mensajes autodescriptivos

6.4 Hipermedia como motor del estado de la aplicación
(HATEOAS)

GSyC - 2016

REST

11

6.1 Identificación de recursos

Introducción a REST

Los recursos individuales se identifican en las peticiones,
típicamente mediante URIs en sistemas web.

El recurso es una cosa y la representación es otra

Por ejemplo un recurso (un fichero) se puede servir
representado en HTML, en XML o JSON. Pero ninguno de
estos formatos tiene por qué ser el formato en que el recurso
es almacenado en la base de datos

GSyC - 2016

REST

12

6.2 Manipulación de recursos mediante representaciones

Introducción a REST

En necesario desacoplar el recurso de la representación del recurso.

El recurso tiene una única URI para todos los formatos

En las cabeceras, cliente y servidor negocian qué formatos
soportan, prefieren o solicitan de cada recurso.

No hay una URI diferente para cada formato, cada formato no
se entiende como una entidad separada

Recordatorio:

URI: Uniform Resource Identifier

URL: Uniform Resource Locator

URN: Uniform Resource Name

Un identificador (URI) puede ser o bien una dirección (URL) o bien
un nombre (URN) o bien ambas cosas

GSyC - 2016

REST

13

6.3 Mensajes autodescriptivos

Introducción a REST

Cada mensaje contiene toda la información necesaria para ser
procesado.

Ejemplo: Internet Media Type (antiguamente llamado tipo
MIME)

Contraejemplo: Fichero de texto code page

GSyC - 2016

REST

14

6.4 Hipermedia como motor del estado de la aplicación

Introducción a REST

HATEOAS, Hypermedia as the engine of application state

Las transiciones entre estados se especifican en un documento
HTML, que devuelve el servidor

El cliente puede descubrir por si mismo los estados a los que
puede pasar, mediante información que le pasa en el servidor,
en formato hipermedia (enlaces html), sin necesidad de
instrucciones adicionales fuera de banda

GSyC - 2016

REST

15

ROA: Resource-Oriented Architecture

ROA: Resource-Oriented Architecture

L. Richardson y S.Ruby en su libro de 2007 RESTful Web Services
proponen una arquitectura concreta, RESTful, a la que denominan
ROA: Resource-Oriented Architecture

La mayoría de los servicios RESTful actuales siguen esta
arquitectura ROA

Aunque sus usuarios pueden no reconocer este nombre

Hay arquitecturas que se autodenominan RESTful, pero que
no siguen estas pautas, resulta discutible que sean
verdaderamente RESTful

GSyC - 2016

REST

16

ROA: Resource-Oriented Architecture

Las pautas de Richardson y Ruby para hacer servicios RESTful son
muy similares a las características definidas por Fielding, pero un
poco más concretas

1 La arquitectura está basada en recursos (resources)

2 Todo recurso tiene que tener una URI

3 Las aplicaciones son direccionables (Addressability)

4 El servidor no tiene estado (es stateless)

5 Las aplicaciones usan un interfaz uniforme: GET, PUT,

DELETE

GSyC - 2016

REST

17

ROA: Resource-Oriented Architecture

1. La arquitectura está basada en recursos

Un recurso resource es cualquier cosa con suficiente entidad como
para merecer ser nombrado e indentificado por sí mismo:

La versión 1.0.3 de cierto software

Un vídeo

Una entrada en un blog

Un mapa de Fuenlabrada

El precio actual del bitcoin en euros en Kraken

...

GSyC - 2016

REST

18

ROA: Resource-Oriented Architecture

2. Todo recurso tiene que tener una URI

Si no tiene URI, no es un recurso
Y la estructura tiene que ser homogénea y predecible

http://www.ejemplo.com/sowtware/releases/1.0.3.tgz

http://www.ejemplo.com/videos/helloworld

http://www.example.com/blog/2016/04/20

http://www.example.com/mapas/ES/MAD/fuenlabrada

http://www.example.com/bitcoin/kraken/BTCEUR

GSyC - 2016

REST

19

ROA: Resource-Oriented Architecture

3. Las aplicaciones son direccionables

Addressability
Una aplicación es direccionable si expone todos sus datos
relevantes como recursos
Ejemplo:

http://www.google.com/search?q=fuenlabrada

Esto es muy importante, cuando no existía este concepto, por
ejemplo con el protocolo FTP, había que dar indicaciones como
abra una sesión FTP con el usuario anonymous, cambie el
directorio a pub/files/ y descargue el fichero file.txt

GSyC - 2016

REST

20

ROA: Resource-Oriented Architecture

Por ser las aplicaciones direccionables, se puede:

Crear un marcador

Crear una URI, ponerla por escrito, en un email, en un QR

Enlazar desde otra página web

Usar una cache

De forma que la segunda vez que se pida el recurso, no se
vuelva a consultar la fuente original sino que se sirve la versión
en cache (tomando las precauciones necesarias para no servir
información anticuada)

GSyC - 2016

REST

21

ROA: Resource-Oriented Architecture

La página que usa Iberia en 2016 para localizar un vuelo, no
es RESTful, no es direccionable
http://www.iberia.com/es/arrivals-and-departures/

No es posible enviar por correo un enlace a tu vuelo
Para ser REST, debería ser algo así
http://www.iberia.com/flights/ib3214/20160329

GSyC - 2016

REST

22

ROA: Resource-Oriented Architecture

No solo las direcciones web son direccionables, por ejemplo
también es direccionable

Un sistema de ficheros

/home/jperez/st/ejemplo.txt

Las celdas de una hoja de cálculo

Algo tan sencillo como ponerle una URI a un folleto para que la
gente lo pueda ver en su navegador no sería posible sin el
direccionamiento

GSyC - 2016

REST

23

ROA: Resource-Oriented Architecture

Si un servicio web es direccionable, los clientes pueden usarlos
de formas nuevas, no previstas en el diseño original

Facilita el ser usado desde distintos dispositivos: aplicaciones
de escritorio, clientes web, clientes nativos para smartphone
(iOS, android, BlueBerry...)

GSyC - 2016

REST

24

ROA: Resource-Oriented Architecture

4. El servidor no tienen estado

Cada petición es independiente de las anteriores

Ejemplo: una búsqueda en google devuelve 10 entradas, cada
una de ellas contien