1.
ARQUITECTURA REST
Universidad de Burgos
Burgos, 3 de Diciembre de 2014

2.
Arquitectura REST 2|
Índice
Qué no es REST
Introducción
Restricciónes
Richardson Madurity Model
Rest Anti Patterns
Seguridad
Documentación
Algunos Frameworks Java y PHP
Demo Time
Q&A

3.
Arquitectura REST 3|
REST NO ES …
REST no es un tecnología.
REST no es un framework.
REST no es un patrón de diseño.
REST no es un protocolo.
REST no es un estándar.
Arquitectura REST

4.
Arquitectura REST 4|
¿QUÉ ES REST?
REST is a coordinated set of architectural
constraints that attempts to minimize latency
and network communication while at the same
time maximizing the independence and scalability
of component implementations.
Arquitectura REST
Roy Fielding
Tesis Doctoral
Architectural Styles and the Design of Network-
based Software Architectures, University of
California, Irvine, 2000

5.
Arquitectura REST 5|
DESCRIPCIÓN GENERAL
REST == REpresentational State Transfer
Basado en Recursos (Elemento de información)
Representación (Formato de la información)
Restricciones:
 Client-Server
 Stateless
 Cacheable
 Uniform Interface
 Layered System
 Code-on-demand
Arquitectura REST

6.
Arquitectura REST 6|
RESTRICCIONES: CLIENT-SERVER
Separación de responsabilidades.
Mejora la portabilidad a distintas plataformas.
Aumento de la escalabilidad.
Componentes evolucionan de forma
independiente.
Arquitectura REST

7.
Arquitectura REST 7|
RESTRICCIONES: STATELESS
Cada petición contiene toda la información
necesaria para que el servidor la procese.
El estado de sesión se mantiene totalmente en el
cliente.
Componentes evolucionan de forma
independiente.
Arquitectura REST

8.
Arquitectura REST 8|
RESTRICCIONES: CACHEABLE
Respuestas del servidor (representaciones)
son cacheables:
 Implícita
 Explicita
 Negociables
Arquitectura REST

9.
Arquitectura REST 9|
RESTRICCIONES: UNIFORM INTERFACE
Principal característica diferenciadora frente a
otras arquitecturas.
Las implementaciones se separan de los
servicios que proporcionan
¿Cómo?
 Verbos HTTP
 URIs (nombres de recursos)
 Respuestas HTTP (status, body)
Arquitectura REST

10.
Arquitectura REST 10|
RESTRICCIONES: LAYERED SYSTEM
Los servicios REST están orientados a la
escalabilidad.
El cliente no sabe si la petición se realiza
directamente a un servidor, un sistema de
cachés o por ejemplo un balanceador que se
encarga de redirigirlo hacia un servidor final.
Arquitectura REST

11.
Arquitectura REST 11|
RESTRICCIONES: CODE-ON-DEMAND
Servidor puede extender o personalizar
temporalmente la funcionalidad del cliente.
Transferencia de la lógica al cliente.
Cliente ejecuta la lógica.
Restricción opcional
Ejemplos:
 Java Applets
 JavaScript
Arquitectura REST

12.
Arquitectura REST 12|
OBJETIVOS
Simplicidad
Escalabilidad
Portabilidad
Independizar el cliente/servidor
Sintaxis “universal”
Sistemas tolerantes al cambio
Minimizar la latencia
Arquitectura REST

13.
Arquitectura REST 13|
RICHARDSON MATURITY MODEL
Arquitectura REST

14.
Arquitectura REST 14|
LEVEL 0: THE SWAMP OF POX (PLAIN OLD XML)
Arquitectura REST
Una URI, un Método HTTP
HTTP como un sistema de transporte para
interacciones remotos
Basado en Remote Procedure Invocation.
XML-RPC y SOAP

15.
Arquitectura REST 15|
LEVEL 1: RESOURCES
Arquitectura REST
URI (Uniform Resource Identifier)
Los nombres de URI no deben implicar una
acción
Evitar uso de verbos.
Deben ser Únicas
Independientes del formato.
Deben mantener una jerarquía lógica.
Los filtrados de información de un recurso no se
hacen en la URI.

16.
Arquitectura REST 16|
LEVEL 1: RESOURCES
Arquitectura REST

17.
Arquitectura REST 17|
LEVEL 1: RESOURCES
Arquitectura REST

18.
Arquitectura REST 18|
LEVEL 2: HTTP VERBS
GET para obtener la representacion/es de un
recurso/s
POST para crear un recurso
PUT para modificar un recurso
DELETE para eliminar un recuerso
PATCH para actualizar parcialmente un recurso
 Uso de HTTP Status Code para indicar el resultado:
 HTTP/1.1 2xx Petición Correcta
 HTTP/1.1 4xx Errores del Cliente
 HTTP/1.1 5xx Errores en el Servidor
Arquitectura REST

19.
Arquitectura REST 19|
LEVEL 2: HTTP VERBS
Arquitectura REST

20.
Arquitectura REST 20|
LEVEL 3: HYPERMEDIA CONTROLS
Arquitectura REST
HATEOS (Hypermedia as the Engine of Application
State)
API debe poder ser navegable sin documentación

21.
Arquitectura REST 21|
LEVEL 3: HYPERMEDIA CONTROLS
Arquitectura REST

22.
Arquitectura REST 22|
LEVEL 3: HYPERMEDIA CONTROLS (EJEMPLO)
Arquitectura REST

23.
Arquitectura REST 23|
LEVEL 3: HYPERMEDIA CONTROLS (EJEMPLO)
Arquitectura REST

24.
Arquitectura REST 24|
REST ANTI-PATTERS BY STEFAN TILKOV
Todas las peticiones a través de GET
Todas las peticiones mediante POST
Cache, ¿qué cache?????
No utilizar códigos de respuesta
Mal uso de cookies
Olvidarnos de Hypermedia
Haciendo caso omiso de los tipos MIME
Mal uso de las cabeceras HTTP
Arquitectura REST

25.
Arquitectura REST 25|
SEGURIDAD
Arquitectura REST
Recordad que nuestros servicios web deben ser
stateless (sin estado):
 No utilizar cookies o HTTP Session.
 El cliente debe enviar las credenciales de
autenticación en cada llamada.
Opciones:
 HTTP Security
 OAuth

26.
Arquitectura REST 26|
DOCUMENTACIÓN
Arquitectura REST
JavadocTagsForExtendedWADL
 Permite añadir más información al WADL.
 Se puede aplicar un transformada para generar
documentación ad hoc.
Swagger
 Ampliamente extendido y estable.
 Independiente del lenguaje de programación.
 UI para probar los servicios.

27.
Arquitectura REST 27|
ALGUNOS FRAMEWORKS JAVA Y PHP
Arquitectura REST

28.
Arquitectura REST 28|
https://github.com/hfuentepe/basic-jersey.git

29.
Arquitectura REST 29|

30.
Arquitectura REST 30|
LECTURAS RECOMENDADAS
Arquitectura REST

31.
Héctor Fuente Pérez
fuenteperez.es
@hfuentepe