Tema 3.2.1: El Estilo Arquitectónico REST

Transcripción

1 Tema 3.2.1: El Estilo Arquitectónico REST

2 Índice Introducción Introducción a HTTP Conceptos básicos de REST Recursos y Representaciones Cambio de estado Características de un Servicio Web REST Ejemplo: Movies RPC vs Movies REST REST vs RPC Valoración y Conclusiones

3 Introducción REpresentational State Transfer. Estilo arquitectónico propuesto por Roy Fielding en La Web es, sin duda, la aplicación distribuida más exitosa de la historia. REST: Estilo arquitectónico para construir aplicaciones distribuidas inspirado en las características de la web. REST se basa fuertemente en HTTP. Frecuentemente REST se utiliza como sinónimo de servicios web que, en lugar de las tecnologías SOAP, utilizan directamente HTTP y XML. Ejemplo: Información de películas en el tema 2.

4 Introducción a HTTP HTTP: HyperText Transfer Protocol. Estandarizado por el W3C y la IETF. La versión actual es HTTP 1.1. Protocolo cliente/servidor utilizado en la Web. Inicialmente construido para transferir páginas HTML. Esquema petición/respuesta. Utiliza TCP para comunicar cliente y servidor (puerto reservado: 80). Desde HTTP 1.1, una conexión HTTP puede utilizarse para varias peticiones. Concepto clave: URL como identificador de recurso.

5 Peticiones HTTP (1) Una petición HTTP consta de: Una URL y un método de acceso (GET, POST, PUT, ). Cabeceras. Metainformación de la petición. Cuerpo del mensaje (opcional). Métodos de acceso: GET: Solicita una representación del recurso especificado. No debe causar efectos secundarios (modificaciones en el recurso). POST: Envía datos para que sean procesados (e.g. formularios) al recurso indicado. Puede crear un nuevo recurso, modificar un recurso existente o ambas cosas. PUT: Carga en el servidor una representación de un recurso. DELETE: Elimina el recurso especificado.

6 Peticiones HTTP (2) Peticiones GET, PUT, DELETE deben ser idempotentes. Múltiples peticiones iguales deben tener el mismo efecto que una sola. Las peticiones GET: No tienen cuerpo del mensaje. Pueden especificarse parámetros en la URL (consultas). Se especifican como pares campo=valor, separados por el carácter &. No deben tener efectos secundarios. Las peticiones POST: Normalmente los datos van en el cuerpo del mensaje. Pueden causar efectos secundarios: Crear un nuevo recurso Modificar un recurso existente

7 Respuestas HTTP Una respuesta HTTP contiene: Código de Status: 200: OK. 404: Recurso no encontrado. 500: Error en el servidor. 403: Error de autorización. Cabeceras. Metainformación de la respuesta. Cuerpo del mensaje: Representación del recurso invocado. o mensaje de error.

8 Cabeceras HTTP Especifican metainformación sobre las peticiones / respuestas. Entre otras: Tipo de datos esperados / devueltos como respuesta. Codificación esperada / devuelta. Lenguaje esperado / devuelto. Antigüedad de la respuesta. Control de cache (e.g. tiempo de expiración, última modificación, ) Credenciales de autorización. Información para proxies. Información para Autenticación. Agente del usuario (e.g. navegador utilizado).

9 Recursos y Representaciones (1) Una aplicación REST se compone de recursos. Cada recurso es identificado mediante una URL: Puede representar un 747 de la compañía Boeing Amelie en la BD de películas de movieprovider.com. Approach/dp/ / El libro Ajax and REST Recipes: A Problem-Solution Approach (ISBN: ) en Amazon. Representa la información sobre HTTP proporcionada por Wikipedia. Los identificadores (URLs) son globales. Todo recurso tiene un nombre único a nivel mundial. No existen espacios de nombres restringidos a una aplicación. Eso no quiere decir que todos los recursos sean accesibles para todos (mecanismos de autorización).

10 Recursos y Representaciones (y2) Al invocar la URL, el cliente obtiene una representación del recurso. La representación de un recurso puede variar en el tiempo. El identificador está ligado al recurso, no a la representación. Si cambian los datos sobre HTTP en la Wikipedia, cambiará la representación. La URL apuntará siempre a la representación actual del recurso (entrada actual en Wikipedia). La representación puede permitir actuar sobre el recurso. Ejemplo: Formularios para introducir datos. La representación puede contener nuevas URLs hacia otros recursos. Ejemplo: cuando atravesamos un hiperenlace (URL) en la web estamos accediendo a un recurso cuya representación (página web) puede contener otros hiperenlaces.

11 Cambio de Estado La representación recibida por el cliente cambia (transfer) su estado (state). Una aplicación REST (web) puede verse como el grafo de transición de estados de un autómata. Las representaciones de recursos (páginas) son estados del autómata. Las URLs (hiperenlaces) son transiciones entre estados. El estado en el que estamos determina qué otros estados (recursos) tenemos accesibles.

12 Características Servicios REST(1) Cliente- Servidor. Clientes invocan URLs para obtener representaciones (modelo pull ). Sin estado. Cada petición de un cliente debe contener toda la información necesaria. No puede beneficiarse de contexto almacenado en servidor. Recursos con nombre Un servicio web REST consiste en la manipulación de recursos usando sólo GET, POST, DELETE, PUT. El espacio de nombres es global. Representaciones de recursos interconectadas Representaciones de recursos se interconectan mediante URLs, permitiendo al cliente cambiar de estado.

13 Características Servicios REST (2) Interfaz uniforme. El acceso a los datos se realiza con un conjunto de operaciones uniformes. (HTTP: GET, POST, PUT, DELETE) Analogía con QUERY / UPDATE / INSERT /DELETE en una Base de datos. Un servicio web REST debe utilizar sólo estas operaciones para manipular los recursos. Esto quiere decir que cierta semántica de una invocación ( lo que hace ) es conocida sin saber nada sobre el servicio. Facilita la interoperabilidad entre aplicaciones. Para manipular un recurso de otra aplicación sólo se precisa su URL. Este conocimiento semántico limitado es suficiente para permitir capas intermedias transparentes que proporcionan servicios útiles. E.g. Una capa cache intermedia sabe que una petición PUT, POST o DELETE invalida la copia cacheada de un recurso.

14 Características Servicios Web (3) Intermediarios: Cache HTTP Servicio-1 HTTP HTTP Servicio-2 Cliente HTTP... Servicio-N

15 Características Servicios REST(y4) Cache: Las representaciones deben poderse marcar como cacheables o no por capas intermedias. La capacidad para soportar niveles intermedios transparentes de cache es una de las claves de la escalabilidad de la Web (e.g. proxies, Akamai Network). Sistema en capas: Pueden introducirse intermediarios de forma transparente entre los clientes y los recursos. Los intermediarios pueden proporcionar servicios de eficiencia, seguridad, Proxies / Cortafuegos Servidores de cache Filtros de contenido

16 Ejemplo: Movies RPC (1) Ejemplo películas al estilo RPC (CORBA, DCOM, SOAP, ) Proveedor proporciona una interfaz que consiste en, entre otras, las siguientes operaciones: MovieSummary [] getmovies() MovieSummary [] getmoviesbydate(calendar date) MovieInformationDetail getmovieinformation (String movieid) String addmovie(movieinformationdetail info) void setmovieinformation (String movieid,movieinformationdetail info) void deletemovie (String movieid) void addgross (double amount, movieid, Calendar week) NOTA: usamos notación a la JAVA. Cuando veamos Servicios web SOAP veremos una notación real.

17 Ejemplo: Movies RPC (2) Los clientes del proveedor suelen utilizar: getmovies permite obtener la lista de todas las películas. getmoviesbydate permite obtener la cartelera de un día determinado. Ambos métodos devuelven la información más importante de una película (objeto MovieSummary).): Se incluye un identificador numérico para cada película. No se devuelve toda la información porque puede ser bastante grande y normalmente no se necesita toda. Si se quiere toda la información de una película puede llamarse a getmovieinformation pasándole el identificador de la película.

18 Ejemplo: Movies RPC (y 3) Las aplicaciones que editan los contenidos del proveedor (internas o externas) suelen utilizar addmovie permite añadir una película. deletemovie permite eliminar una película. setmovieinformation. Permite reemplazar la información completa de una película. addgross. Permite especificar la recaudación semanal de una película. Modifica el atributo recaudación total de la misma sumándole la nueva recaudación. No es idempotente.

19 Ejemplo: Movies REST (1) Cada película es un recurso con una URL asociada: t_ii La representación de ese recurso es un documento XML. Similar al ejemplo utilizado en el tema 2 pero con elementos de datos adicionales (e.g. recaudación, productora, puntero al trailer, punteros a biografías de los actores, ). Podría no utilizarse XML: Si los datos son sencillos. Ejemplo: CSV. Si al cliente puede facilitarle su procesamiento. Ejemplo: desde clientes Javascript, es más fácil usar JSOM.

20 Ejemplo: Movies REST (2) es un recurso que contiene: La información resumida de todas las películas. Una referencia al recurso de cada película. Su representación es un documento XML: <?xml version="1.0"?> <mov:movies xmlns:mov=" xmlns:xlink=" <Movie title= Amelie director= Jean Pierre Jeunet xlink:href=" <Movie title= The Godfather Part II director= Francis Ford Coppola xlink:href=" II"/> </mov:movies> Xlink: forma estándar en XML de expresar referencias a otros recursos. Análogo a una aplicación web convencional.

21 Ejemplo: Movies REST (3) puede recibir parámetros de consulta Qué hacen los clientes ahora? Invocan Si quieren la cartelera, la invocan con parámetros. Parsean el XML para obtener la información resumida. Si quieren la información completa de una película, invocan a su referencia y parsean el XML. Todas son peticiones GET.

22 Ejemplo: Movies REST (y 4) Qué hacen las aplicaciones que editan los contenidos ahora? Para añadir una película, realizan una petición PUT indicando la URL asociada Ejemplo: Los datos de la película van como un documento XML en el cuerpo del mensaje. Para borrar una película invocan el recurso que representa a la película con el método DELETE. Para reemplazar la información de una película invocan el recurso que representa a la película con el método POST. Los datos de la película van como un documento XML en el cuerpo del mensaje. Para incorporar la recaudación de una semana, invocan: Es una invocación POST (no es idempotente). Los datos (URL de la película y recaudación) van en el cuerpo del mensaje en XML. Otra opción: el atributo TotalGross de cada película podría ser un recurso (enfoque REST más puro, pero más incómodo).

23 Ejemplo: REST vs RPC (1) Espacio de nombres global vs local El enfoque RPC utiliza un espacio de nombres local basado en identificadores de película. Los identificadores del enfoque REST son globales. Si otro servicio web (e.g. que proporciona críticas de películas) quiere incluir una referencia a una película de movieprovider.com puede sencillamente incluir su URL en una de sus respuestas. Hace muy fácil reusar recursos y servicios. Fácil compartir contexto (datos, etc.) entre servicios. No existe una posibilidad equivalente en el enfoque RPC. OJO: No es magia, el cliente debe aún conocer el formato XML utilizado por movieprovider.com, pero eso pasa también con los objetos devueltos en el esquema RPC. La causa principal del éxito de la Web no fueron HTML ni HTTP, cuya principal virtud era la simplicidad. La causa principal fue la utilización de un espacio de nombres global que permitía reusar muy fácilmente (mediante enlaces) los contenidos ya existentes.

24 Ejemplo: REST vs RPC (2) Operaciones estándar vs Operaciones no estándar. RPC permite que cada servicio defina sus propias operaciones pero no expone ninguna semántica de las mismas. No puede saberse, por ejemplo, que: La operación addgross no es idempotente y además tiene efectos secundarios. La operación setmovieinformation es idempotente y tiene efectos secundarios. La operación getmovieinformationdetail es idempotente y no tiene efectos secundarios. REST intenta modelar aplicaciones en términos de recursos y usar un conjunto fijo de operaciones: GET, POST, PUT, DELETE. Cierta semántica de estas operaciones es conocida: POST tiene efectos secundarios y no tiene porque ser idempotente. PUT, DELETE tienen efectos secundarios pero son idempotentes. GET es idempotente y no tiene efectos secundarios.

25 Ejemplo: REST vs RPC (3) Operaciones estándar vs Operaciones no estándar (cont.) Conocer algo sobre la semántica de las operaciones permite tener intermediarios que proporcionan valor añadido a CUALQUIER servicio (sin tener que saber nada sobre él a priori). Ejemplos: Un servidor de cache sabe que un recurso al que se haya emitido una petición PUT, DELETE o POST debe ser invalidado. Un proxy que, cuando una petición falla, la reintenta de forma transparente al cliente, sabe que puede reintentar una petición GET sin riesgo (porque es idempotente). Un crawler de recursos ( a la Google ) sabe que debe acceder sólo a recursos usando sólo GET (también por su idempotencia). Las invocaciones RPC no pueden beneficiarse directamente de los servicios de estos intermediarios. RPC es más flexible. Permite tener el API más adecuado a las características de tu aplicación. REST pretende obligar a modelar todas las aplicaciones de la misma forma, y puede no ser fácil o cómodo en todos los casos.

26 Ejemplo: REST vs RPC (4) Accesibilidad REST usa directamente URLs y HTTP: Fácil ver y manipular datos para humanos: puedo acceder a un recurso directamente con un navegador (XML suele ser legible para humanos). Fácil devolver distintas representaciones del recurso. Ejemplo: HTML para usuarios humanos y XML para aplicaciones (cabecera HTTP Agente de Usuario + XSLT). Prácticamente cualquier aplicación (desde Office a los sistemas de integración de datos) puede acceder recursos HTTP. Interoperabilidad garantizada El cliente debe ocuparse de los detalles de ejecutar peticiones HTTP y parsear documentos XML Es bastante fácil en casi todos los lenguajes de programación.

27 Ejemplo: REST vs RPC (5) Accesibilidad (cont.) RPC utiliza librerías y protocolos específicos: No es fácil para un humano acceder rápidamente a los recursos. Hay que construir aplicaciones ad-hoc para ello. Cualquier operación que involucre acceso al recurso implica programar. Para acceder a un servicio RPC, las aplicaciones deberán utilizar librerías generadas específicamente para nuestro servicio. Menor interoperabilidad. El programador no se preocupa de cómo se envían peticiones ni de parsear XML. El sistema RPC le da todo eso resuelto. Puede haber problemas de interoperabilidad entre implementaciones (problema temporal). Ejemplo: Debido a bugs, un servicio SOAP programado con una toolkit puede tener problemas con otro servicio programado con otra toolkit.

28 Ejemplo: REST vs RPC (6) Estandarizar vocabularios vs Estandarizar APIs Para que una aplicación pueda interoperar con un servicio REST: En algunos casos (e.g. caches, crawlers) la semántica implícita en las operaciones GET, PUT, DELETE, POST puede ser suficiente. En general, será necesario que la aplicación conozca el vocabulario XML utilizado por el servicio. Para que una aplicación pueda interoperar con un servicio RPC: Debe, en todos los casos, conocer su API, lo que incluye también sus objetos. Interoperabilidad a gran escala. Qué es más fácil estandarizar? RSS / ATOM. Ejemplo de vocabulario estandarizado exitoso. Hubiese tenido el mismo éxito RSS si fuese un API en lugar de un vocabulario?. Parece difícil.

29 Ejemplo: REST vs RPC (7) Reusar mecanismos genéricos de diseño de HTTP vs Nuevos mecanismos Con REST, pueden reusarse directamente los mecanismos de autorización (permisos de acceso), cifrado y autenticación de HTTP. Con esquemas RPC, deben crearse nuevos mecanismos para esto: En algunas tecnologías como CORBA ya existen. En el mundo SOAP no existen pero se están construyendo. Pueden crearse para que mejoren a los de HTTP. HTTP no tiene todo lo necesario (e.g. transacciones distribuidas, servicios de mensajería, ). Los defensores de REST proponen extender HTTP en lugar de crear nuevos protocolos.

30 Ejemplo: REST vs RPC (y 8) Transporte fijo vs Independiente Transporte Con REST, el protocolo encargado de transferir las peticiones es siempre HTTP. Los sistemas RPC pueden utilizar diversos protocolos: Ejemplo: SOAP puede funcionar sobre HTTP, SMTP, JMS, Los defensores de REST dicen que prácticamente siempre se usa HTTP también en RPC (SOAP casi siempre va sobre HTTP). Defensores de RPC dicen que HTTP a veces es inadecuado: Es poco eficiente. Hay muchas cosas que no soporta: Ejemplo: HTTP no puede garantizar la entrega de un mensaje. Hay servicios web reales que utilizan SOAP sobre JMS, porque JMS sí proporciona esa funcionalidad.

31 REST en la Práctica Normalmente sólo se utilizan GET (lectura) y POST (escritura) Prácticamente siempre hay recursos que realmente implementan operaciones no estándar: E.g. addgross. Pocas veces se asignan URLs a recursos que no representen realmente operaciones sino objetos. A pesar de esto, algunas de las ventajas más importantes se mantienen: Caches Accesibilidad sigue siendo mejor. Aprovechamiento de los mecanismos de HTTP. En los siguientes apartados y en la práctica utilizaremos el enfoque no purista.

32 Conclusiones REST es un nuevo estilo arquitectónico para construir aplicaciones distribuidas basadas en los principios que hicieron exitosa a la web. REST tiene el potencial para permitir la construcción de aplicaciones distribuidas más escalables e interoperables que las actuales. REST es más accesible. Casi cualquier aplicación puede acceder fácilmente a recursos REST. RPC es más flexible (REST obliga a modelar la aplicación de una forma concreta) y más amigable para el programador (independiente de XML y HTTP). La mayoría de aplicaciones distribuidas corporativas y B2B siguen modelándose según la arquitectura RPC, aunque REST tiene su importancia y gana terreno. A menudo, REST se usa para referirse a servicios web que usan exclusivamente HTTP / XML (en lugar de SOAP), incluso si la arquitectura de dichos servicios es básicamente RPC. Estos servicios se benefician de parte de las ventajas de REST.