Representational State Transfer (REST)

1. Representational State Transfer (REST) PROYECTO FIN DE CARRERA: Tutor: Antonio J. Sierra Collado Alumno: Alberto Cubo Velázquez

2. ÍNDICE • INTRODUCCIÓN • HTTP, URI, XML • SOAP Y WSDL • REST • DEBATE REST-SOAP • IMPLEMENTACIONES REST • FUTURO DE REST

3. 1. INTRODUCCIÓN

4. INTRODUCCIÓN • Necesidad de realizar tareas en menor tiempo • Internet y Servicios Web como solución

5. SERVICIOS WEB: • Facilitan tareas a los usuarios • Ligadas al mundo Web (Internet) • Datan de las últimas dos décadas • Origen: CORBA, RPC • Actualmente SOAP tiene el monopolio • REST como alternativa a SOAP

6. IMPORTANCIA DE REST EN LA WEB

7. 2. URI, HTTP Y XML

8. URI, HTTP, XML • Identificador de recursos: URI, UUID • Protocolo de Transferencia: HTTP • Descripción y estructurado de datos: XML Bases para construir Servicios Web:

9. 3. SOAP Y WSDL

10. CARACTERÍSTICAS DE SOAP: • Arquitectura de Servicios Web • Creado por IBM, Microsoft y actualmente W3C • Basada en RPC • Intercambio de información entre dos puntos mediante XML • Uso de HTTP como túnel para las comunicaciones • Descubrimiento de Servicios mediante WSDL

11. FUNCIONAMIENTO DE SOAP:

12. MENSAJES SOAP: <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP- ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <getQuote xmlns= "http://namespaces.alberto.org/xmljava/ch2/"> <symbol>RHAT</symbol> </getQuote> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

13. 4. REST

14. CARACTERÍSTICAS • Origen Roy Thomas Fielding, ámbito académico • Estilo de arquitectura • Describe como debería comportarse la Web • Se apoya en el uso de URI y HTTP • REST evoluciona en la red

15. ESTILO DE ARQUITECTURA: • Conjunto coordinado de restricciones que controlan el funcionamiento y características de los elementos de la arquitectura y permite las relaciones de unos con otros.

16. RESTRICCIONES DE REST: • Cliente Servidor • Sin estado • Caché • Sistema de capas • Interfaz Uniforme

17. RESTRICCION 1: CLIENTE-SERVIDOR

18. RESTRICCIÓN 2: SIN ESTADO

19. RESTRICCIÓN 3: CACHÉ

20. RESTRICCIÓN 4: SISTEMA DE CAPAS

21. RESTRICCIÓN 5: INTERFAZ UNIFORME • La implementación se separa del servicio que proporciona. • Mecanismos para conseguirlo: • Recursos e identificación de recursos • Manipulación de recursos a través de sus representaciones • Mensajes Auto-descriptivos • Hipermedios como el motor de estado de la aplicación

22. RECURSOS • REST es orientado a recursos y no a métodos

23. IDENTIFICACIÓN DE RECURSOS • URI Física • URI Lógica

24. MANIPULACIÓN DE RECURSOS • Un cliente manipula la representación de un recurso en vez de su implementación.

25. MENSAJES AUTO-DESCRIPTIVOS • Toda la información necesaria para procesar el mensaje se encuentra en el propio mensaje. • Usa HTTP como protocolo de aplicación.

26. HIPERMEDIO COMO EL MOTOR DE ESTADO

27. MÉTODOS DE REST • Usa los métodos de HTTP • Cumple con la restricción de interfaz uniforme

28. BENEFICIOS OBTENIDOS AL USAR REST • Mejora el tiempo de respuesta gracias al mecanismo Caché y los mensajes auto-descriptivos • Mejora la seguridad debido a los mensajes auto-descriptivos y el uso de los métodos HTTP

29. 5. DEBATE REST-SOAP

30. DEBATE REST-SOAP • Inicio junto con la disertación de Roy Fielding • Los adeptos a REST buscan los puntos débiles de SOAP • A veces toma un tono político al unir SOAP con Microsoft • Principales autores: Paul Prescod, Tim Bray, Robert McMillan, Sam Ruby…

31. DIFERENCIAS ENTRE REST Y SOAP

32. CRÍTICAS DE REST HACIA SOAP • SOAP no es transparente, apuesta por el encapsulamiento • SOAP no dispone de un sistema de direccionamiento global • SOAP puede derivar en agujeros de seguridad • SOAP no aprovecha muchas de las ventajas de HTTP al usarlo solamente como túnel • SOAP no puede hacer uso de los mecanismos Caché

33. CRÍTICAS DE SOAP HACIA REST • REST es poco flexible • REST no está preparado para albergar Servicios Web de gran complejidad como las aplicaciones B2B • REST falla a la hora de realizar Servicios Web que necesiten procesado de datos • REST tiene grandes problemas de seguridad al no soportar el concepto de sesión

34. 6. IMPLEMENTACIONES

35. AMAZON • Pionera en el uso de REST en 2002, muy comentado en la Web • Base de datos con todos los productos que vende • Los productos se acceden como recursos, no como métodos de búsqueda • API disponible en associates.amazon.com • Posible carencia, si realiza servicios más sofisticados puede que deba migrar a SOAP

36. eBay • Desarrolló una API REST en 2004 • Consulta de productos a través del método GetSearchResults() • Ejemplo de uso: http://rest.api.ebay.com/restapi?CallName=GetSearchResults&RequestToken =xyz123&RequestUserId=ebayuser&Query=toy%20boat&Schema=1 • Fallo, usa un método con parámetros para invocar un producto

37. RESTLETS • API desarrollada en 2006 • Funcionando aunque en fase de depuración • Acerca REST a los desarrolladores Java • Realiza las mismas funciones de los Servlets pero al estilo REST

38. 7. FUTURO DE REST

39. FUTURO DE REST • SOAP mantiene el monopolio de los Servicios Web • Carencia de documentación • Escasas implementaciones y ejemplos prácticos para acercar REST al programador común • Única solución, crear organización o entidad que agrupe el disperso y escaso trabajo que existe sobre REST