1. REST & JERSEY
Fernando Román
Oriol Ramírez
Albert Raventós

2. INTRODUCCIÓN
• REST == “Representational State Transfer”
• Es una Arquitectura de servicios distribuidos basada en
estándares web y HTTP
• Buenas prácticas para servicios distribuidos
• Descrita en por Roy Fielding en el año 2000
• Basada en recursos
• Los recursos pueden tener diferentes representaciones

3. SERVICIOS RESTFul
• Un servicio es REST si cumple estas 6 Restricciones:
• Uniforme
• Sin estados (Stateless)
• Modelo Cliente-Servidor
• Cacheable
• Sistema bajado en Capas (Layered System)
• Ejecución de código bajo demanda

4. BASADO EN RECURSOS
• Objetos vs. Acciones
• Nombres vs. Verbos
• SOAP - Simple Object Access Protocol
• Recursos identificados por IDs únicas(URIs)
• Múltiples URIs pueden apuntar a un recurso pero cada URI solo
puede apuntar a un recurso.

5. REPRESENTACIONES
• CRUD: Create – Read – Update – Delete
• REST va más alla porque soporta muchas representaciones
para un mismo recurso:
• XML, PDF, PNG, JSON, HTML, TEXTO…
• Cada recurso tiene un estado interno que no puede ser
accedido directamente desde el exterior
• Una representación es el formato de datos utilizado para la
transferencia del estado público de un recurso.
• Diferentes formatos de representación pueden proporcionar
diferentes datos de un recurso.

6. Uniform Interface I
• Define la interfaz entre cliente y servidor
• Simplifica y separa la arquitectura
• Es fundamental para el diseño RESTful
• Significa:
• HTTP verbs (GET, PUT, POST, DELETE)
• URIs (nombres de recursos)
• HTTP response (status, body)

7. Uniform Interface II
• Basado en recursos
• La manipulación de los recursos a través de representaciones
• Mensajes auto-descriptivos
• Hypermedia as the Engine of Application State (HATEOAS)

8. STATELESS
• El servidor no contiene estados de cliente
• Cada request contiene suficiente información para procesar el
mensaje
• Mensajes autp-descriptivos
• Cualquier estado de sesión es ayudar en el cliente

9. Client-Server
• Suponemos que es un sistema desconectado
• Separación de problemas
• Una interfaz uniforme es la conexión entre ambos lados

10. CACHE
• Las respuestas del servidor (representaciones) se pueden
cachear
• Implicitly
• Explicitly
• Negociated

11. LAYERED SYSTEM
• El cliente no puede asumir una conexión directa con el
servidor
• Software o hardware intermediarios entre el cliente y el
servidor
• Mejora la escalabilidad

12. CODE ON DEMAND
• Servidor puede extender temporalmente cliente
• Transferir la lógica al cliente
• El cliente calcula
• Por ejemplo:
• Java applets
• JavaScript
• La única restricción opcional

13. REST vs RPC
• REST: Proporciona al cliente una interfaz sencilla de acceso a
los recursos, 4 acciones posibles.
• RPC: Proporciona gran cantidad de acciones (metodos) a
ejecutar sobre los recursos.

14. Ejemplo REST vs RPC
• Cómo obtener la lista de ciudades de España:
• RPC: listcities(Spain)
• REST: GET a la URL
http://www.example.org/service?country=Spain
• Generación dinámica de representaciones
• URIs Opacas vs URIs Constructivas

15. REST vs SOAP
• SOAP también está orientado a objetos pero no existe un
conjunto de operaciones estándar.
• Cada sistema SOAP requiere de un cliente que implemente el
conjunto de operaciones que soporta.

16. CONCLUSIONES
• Para que un servicio sea RESTFul debe cumplir todas las
limitaciones
• Cumplir con REST nos permite obtener servicios distribuidos
• Escalables
• Simples
• Robustos

17. Jersey
• Una manera de aplicar REST en Java.

18. Jersey
• Facilita la manera de obtener los objetos.
• Se puede combinar con JSON para enviarlos
• Ejemplo
• REST puede ser una manera útil y clara para pasar objetos a
otros dispositivos (android, clientes de consola, etc);