Download - Arquitectura REST
ARQUITECTURA RESTUniversidad de Burgos
Burgos, 3 de Diciembre de 2014
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
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
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
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
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
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
Arquitectura REST 8|
RESTRICCIONES: CACHEABLE
Respuestas del servidor (representaciones)
son cacheables:
Implícita
Explicita
Negociables
Arquitectura REST
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
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
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
Arquitectura REST 12|
OBJETIVOS
Simplicidad
Escalabilidad
Portabilidad
Independizar el cliente/servidor
Sintaxis “universal”
Sistemas tolerantes al cambio
Minimizar la latencia
Arquitectura REST
Arquitectura REST 13|
RICHARDSON MATURITY MODEL
Arquitectura REST
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
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.
Arquitectura REST 16|
LEVEL 1: RESOURCES
Arquitectura REST
Arquitectura REST 17|
LEVEL 1: RESOURCES
Arquitectura REST
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
Arquitectura REST 19|
LEVEL 2: HTTP VERBS
Arquitectura REST
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
Arquitectura REST 21|
LEVEL 3: HYPERMEDIA CONTROLS
Arquitectura REST
Arquitectura REST 22|
LEVEL 3: HYPERMEDIA CONTROLS (EJEMPLO)
Arquitectura REST
Arquitectura REST 23|
LEVEL 3: HYPERMEDIA CONTROLS (EJEMPLO)
Arquitectura REST
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
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
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.
Arquitectura REST 27|
ALGUNOS FRAMEWORKS JAVA Y PHP
Arquitectura REST
Arquitectura REST 28|
https://github.com/hfuentepe/basic-jersey.git
Arquitectura REST 29|
Arquitectura REST 30|
LECTURAS RECOMENDADAS
Arquitectura REST
Héctor Fuente Pérez
fuenteperez.es
@hfuentepe