1 REST
2 ¿Qué es un Servicio Web? W3C define los Servicios Web como sistemas software diseñados para soportar una interacción interoperable maquina a maquina sobre una red. Los Servicios Web suelen ser APIs Web que pueden ser accedidas dentro de una red (principalmente Internet) y son ejecutados en el sistema que los aloja. La definición de Servicios Web propuesta alberga muchos tipos diferentes de sistemas, pero el caso común de uso de refiere a clientes y servidores que se comunican mediante mensajes XML que siguen el estándar SOAP.
3 Estilo de arquitectura Software REST En los últimos años se ha popularizado un estilo de arquitectura Software conocido como REST (Representational State Transfer). Este nuevo estilo ha supuesto una nueva opción de estilo de uso de los Servicios Web.
4 Los tres estilos de usos más comunes Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos): Los Servicios Web basados en RPC presentan una interfaz de llamada a procedimientos y funciones distribuidas, lo cual es familiar a muchos desarrolladores. Típicamente, la unidad básica de este tipo de servicios es la operación WSDL (WSDL es un descriptor del Servicio Web, es decir, el homologo del IDL para COM). Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA). Los Servicios Web pueden también ser implementados siguiendo los conceptos de la arquitectura SOA, donde la unidad básica de comunicación es el mensaje, más que la operación. Esto es típicamente referenciado como servicios orientados a mensajes. REST (REpresentation State Transfer). Los Servicios Web basados en REST intentan emular al protocolo HTTP mediante la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (por ejemplo GET, PUT,…). Por tanto, este estilo se centra más en interactuar con recursos con estado, que con mensajes y operaciones
5 ¿Qué es REST? REST es un estilo de arquitectura de software para sistemas hipermedias distribuidos tales como la Web. El término fue introducido en la tesis doctoral de Roy Fielding en 2000, quien es uno de los principales autores de la especificación de HTTP. REST se refiere estrictamente a una colección de principios para el diseño de arquitecturas en red. Estos principios resumen como son definidos y diseccionados los recursos. El término frecuentemente es utilizado en el sentido de describir a cualquier interfaz que transmite datos específicos de un domino sobre HTTP sin una capa adicional, como hace SOAP. Estos dos significados pueden chocar o incluso solaparse. ◦Es posible diseñar un sistema software de gran tamaño de acuerdo con la arquitectura propuesta por Fielding sin utilizar HTTP o sin interactuar con la Web. ◦También es posible diseñar una simple interfaz XML+HTTP que no sigue los principios REST, y en cambio seguir un modelo RPC.
6 REST no es un estándar Es tan solo un estilo de arquitectura. Aunque REST no es un estándar, está basado en estándares: HTTP URL Representación de los recursos: XML/HTML/GIF/JPEG/… Tipos MIME: text/xml, text/html, …
7 ¿Cuál es la motivación de REST? Capturar las características de la Web que la han hecho tan exitosa. ◦La Web ha sido la única aplicación distribuida que ha conseguido ser escalable al tamaño de Internet. ◦El éxito lo debe al uso de formatos de mensaje extensibles y estándares, pero además cabe destacar que posee un esquema de direccionamiento global (estándar y extensible a su vez). El concepto central de la Web es un espacio de URIs unificado. Las URIs permiten la densa red de enlaces que permiten a la Web que sea tan utilizada. ◦Por tanto, ellos consiguen tejer una mega-aplicación. Las URIs identifican recursos, los cuales son objetos conceptuales. ◦La representación de tales objetos se distribuye por medio de mensajes a través de la Web. Este sistema es extremadamente desacoplado.
8 Principios de REST Escalabilidad de la interacción con los componentes. La Web ha crecido exponencialmente sin degradar su rendimiento. Prueba de ellos es la variedad de clientes que pueden acceder a través de la Web: estaciones de trabajo, sistemas industriales, dispositivos móviles,… Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuración especial. Esto no es del todo cierto para otras alternativas, como SOAP para los Servicios Web. Puesta en funcionamiento independiente. Este hecho es una realidad que debe tratarse cuando se trabaja en Internet. Los clientes y servidores pueden ser puestas en funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo de características resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las cabeceras, a través de las URIs, a través de la habilidad para crear nuevos métodos y tipos de contenido. Compatibilidad con componentes intermedios. Los más populares intermediaros son varios tipos de proxys para Web. Algunos de ellos, las caches, se utilizan para mejorar el rendimiento. Otros permiten reforzar las políticas de seguridad: firewalls. por último, otro tipo importante de intermediarios, gateway, permiten encapsular sistemas no propiamente Web. Por tanto, la compatibilidad con intermediarios nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.
9 REST logra satisfacer estos objetivos aplicando cuatro restricciones (cont.) Identificación de recursos y manipulación de ellos a través de representaciones. Esto se consigue mediante el uso de URIs. HTTP es un protocolo centrado en URIs. Los recursos son los objetos lógicos a los que se le envían mensajes. Los recursos no pueden ser directamente accedidos o modificados. Más bien se trabaja con representaciones de ellos. Cuando se utiliza un método PUT para enviar información, se coge como una representación de lo que nos gustaría que el estado del recurso fuera. Internamente el estado del recurso puede ser cualquier cosa desde una base de datos relacional a un fichero de texto.
10 REST logra satisfacer estos objetivos aplicando cuatro restricciones (cont.) Mensajes autodescriptivos. REST dicta que los mensajes HTTP deberían ser tan descriptivos como sea posible. Esto hace posible que los intermediarios interpreten los mensajes y ejecuten servicios en nombre del usuario. Uno de los modos que HTTP logra esto es por medio del uso de varios métodos estándares, muchos encabezamientos y un mecanismo de direccionamiento. Por ejemplo, las cachés Web saben que por defecto el comando GET es cacheable (ya que es side-effect-free) en cambio POST no lo es. Además saben como consultar las cabeceras para controlar la caducidad de la información. HTTP es un protocolo sin estado y cuando se utiliza adecuadamente, es posible es posible interpretar cada mensaje sin ningún conocimiento de los mensajes precedentes. Por ejemplo, en vez de logearse del modo que lo hace el protocolo FTP, HTTP envía esta información en cada mensaje.
11 REST logra satisfacer estos objetivos aplicando cuatro restricciones (cont.) Hipermedia como un mecanismo del estado de la aplicación. El estado actual de una aplicación Web debería ser capturada en uno o más documentos de hipertexto, residiendo tanto en el cliente como en el servidor. El servidor conoce sobre le estado de sus recursos, aunque no intenta seguirle la pista a las sesiones individuales de los clientes. Esta es la misión del navegador, el sabe como navegar de recurso a recurso, recogiendo información que el necesita o cambiar el estado que el necesita cambiar.
12 ¿Quién aplica estas restricciones? En la actualidad existen millones de aplicaciones Web que implícitamente heredan estas restricciones de HTTP. Hay una disciplina detrás del diseño de sitios Web escalables que puede ser aprendida de los documentos de arquitectura Web o de varios estándares. ◦También es verdad que muchos sitios Web comprometen uno más de estos principios, como por ejemplo, seguir la pista de los usuarios moviéndose a través de un sitio. ◦Esto es posible dentro de la infraestructura de la Web, pero daña la escalabilidad, volviendo un medio sin conexión en todo lo contrario. Los defensores de REST han creído que estas ideas son tan aplicables a los problemas de integración de aplicaciones como los problemas de integración de hipertexto. Fielding es bastante claro diciendo que REST no es la cura para todo. Algunas de estas características de diseño no serán apropiadas para otras aplicaciones. Sin embargo, aquellos que han decidido adoptar REST como un modelo de servicio Web sienten que al menos articula una filosofía de diseño con fortaleza, debilidades y áreas de aplicabilidad documentada.
13 ¿Cómo sería un ejemplo de diseño basado en REST? La Web consiste del protocolo HTTP, de tipos de contenido, incluyendo HTML y otras tecnologías tales como el Domain Name System (DNS). Por otra parte, HTML puede incluir javascript y applets, los cuales dan soporte al code-on- demand, y además tiene implícitamente soporte a los vínculos. HTTP posee un interfaz uniforme para acceso a los recursos, el cual consiste de URIs, métodos, códigos de estado, cabeceras y un contenido guiado por tipos MIME. Los métodos HTTP más importantes son PUT, GET, POST y DELETE. ◦Suelen ser comparados con las operaciones asociadas a la tecnología de base de datos, operaciones CRUD: CREATE, READ, UPDATE, DELETE. ◦Otras analogías pueden también ser hechas como con el concepto de copiar-y-pegar (Copy&Paste). Todas las analogías se representan en la siguiente tabla:
14 AcciónHTTPSQLCopy&PasteUnix Shell CreatePUTInsertPegar> ReadGETSelectCopiar< UpdatePOSTUpdatePegar después>> DeleteDELETEDeleteCortarDel/rm
15 Comentarios Acciones (verbos) CRUD: Se diseñaron para operar con datos atómicos dentro del contexto de una transacción con la base de datos. REST se diseña alrededor de transferencias atómicas de un estado más complejo, tal que puede ser visto como la transferencia de un documento estructurado de una aplicación a otra. El protocolo HTTP separa las nociones de un servidor y un navegador. ◦Esto permite a la implementación cada uno variar uno del otro, basándose en el concepto cliente/servidor. Cuando utilizamos REST, HTTP no tiene estado. Cada mensaje contiene toda la información necesaria para comprender la petición cuando se combina el estado en el recurso. ◦Como resultado, ni el cliente ni el servidor necesita mantener ningún estado en la comunicación. Cualquier estado mantenido por el servidor debe ser modelado como un recurso transferencia de un documento estructurado de una aplicación a otra.
16 Comentarios (cont.) La restricción de no mantener el estado puede ser violada mediante cookies que mantienen las sesiones. Fielding advierte del riesgo a la privacidad y seguridad que frecuentemente surge del uso de cookies, así como la confusión y errores que pueden resultar de las interacciones entre cookies y el uso del boton “Go back” del navegador.
17 ¿Cómo crear una interfaz basada en REST?
18 En vez de cubrir esto desde un punto de vista arquitectural, es aconsejable realizarlo a modo de receta. Existen una serie de pasos a tomar y una serie de preguntas a responder. Antes de empezar a pensar en el servicio, debemos responder las siguientes preguntas en orden: 1.¿Qué son las URIs? 2.¿Cuál es el formato? 3.¿Qué métodos son soportados en cada URI? 4.¿Qué códigos de estado pueden ser devueltos?
19 ¿Qué son las URIs? Las cosas identificadas por URIs son “recursos”. Aunque es más apropiado decir que los Recursos son identificados mediante URIs. Si solo existe una única URI como punto de acceso, posiblemente se esté creando un protocolo RPC. En tal caso, se debe desmenuzar el problema en tipos de recursos que se quieren manipular. Dos lugares donde se debe considerar cuando se buscan los recursos potenciales son las colecciones y las interfaces de búsqueda. Una colección de recursos es en si mismo un recurso. Una interfaz de búsqueda también lo es, ya que el resultado de una búsqueda es otro conjunto de recursos. A modo de ejemplo, supongamos un sistema de mantenimiento de una lista de contactos de empleados. En tal sistema cada usuario debería tener su propia URI con una apropiada representación. Además, la colección de recursos es otro recurso. Por tanto, hemos identificado dos tipos de recursos, por tanto habrá dos tipos de URIs: o Employee (Una URI por empleado). o AllEmployee (Listado de los empleados).
20 ¿Cuál es el formato? Cuando hablamos informalmente de formato, estamos hablando de la representación. No se puede acceder directamente al recurso, hay que obtener una representación. ◦Esta representación puede ser un documento HTML, XML, una imagen,… dependiendo de la situación. Para cada uno de los recursos, se tiene que decidir cual va a ser su representación. ◦Si es posible, reutilizar formatos existentes, ayudará a incrementar la oportunidad de que nuestro sistema se componga con otros.
21 ¿Cuál es el formato (cont.)? Continuando con nuestro ejemplo, el formato de representación va a ser XML, ya que es el principal formato para intercambio de información. Para el listado de empleados podríamos tomar este otro: Full name of the first employee goes here. Full name. Full name El formato del empleado podría ser el siguiente: Full name goes here. Persons title goes here. Phone number goes here.
22 ¿Qué métodos son soportados en cada URI? Tenemos que definir como van a ser referenciados los recursos. Por medio de las URIs y los métodos soportados el acceso va a ser posible. El acceso se puede hacer de muchas formas, recibiendo una representación del recurso (GET o HEAD), añadiendo o modificando una representación (POST o PUT) y eliminando algunas o todas las representaciones (DELETE).
23 HTTPCRUDDescripción POSTCREATECrear un nuevo recurso GETRETRIEVEObtener la representación de un recurso PUTUPDATEActualizar un recurso DELETE Eliminar un recurso RecursoMétodoRepresentación EmployeeGETFormato del empleado EmployeePUTFormato del empleado EmployeeDELETE- All EmployeesGETFormato de la lista de empleados All EmployeesPOSTFormato de empleado
24 ¿Qué códigos de estado pueden ser devueltos? No solo es necesario conocer que tipo de representación va a ser devuelta, también es necesario enumerar los códigos de estado HTTP típicos que podrían ser devueltos. Volvemos a actualizar nuestra tabla para mostrar los códigos de estado: RecursoMétodoRepresentaciónCódigos de estado Employee GETFormato del empleado200, 301, 410 Employee PUTFormato del empleado200, 301, 400, 410 Employee DELETE-200, 204 All Employees GET Formato de la lista de empleados 200, 301 All Employees POSTFormato de empleado201, 400
25 Cómo diseñar un servicio Web basado en REST
26 Pautas Las pautas a seguir en el diseño de servicios Web basados en REST son las mismas que las descritas en el apartado dedicado a crear una interfaz REST. Identificar todas las entidades conceptuales que se desean exponer como servicio. Crear una URL para cada recurso. Los recursos deberían ser nombres no verbos (acciones). Por ejemplo no utilizar esto: http://www.service.com/entities/getEntity?id=001 Como podemos observar, getEntity es un verbo. Mejor utilizar el estilo REST, un nombre: http://www.service.com/entities/001 Categorizar los recursos de acuerdo con si los clientes pueden obtener un representación del recurso o si pueden modificarlo. Para el primero, debemos hacer los recursos accesibles utilizando un HTTP GET. Para el último, debemos hacer los recursos accesibles mediante HTTP POST, PUT y/o DELETE. Todos los recursos accesibles mediante GET no deberían tener efectos secundarios. Los recursos deberían devolver la representación del recurso. Invocar al recurso no debería ser el resultado de modificarlo. Ninguna representación debería estar aislada. Es recomendable poner hipervínculos dentro de la representación de un recurso para permitir a los clientes obtener más información. Especificar el formato de los datos de respuesta mediante un esquema (DTD, W3C Schema, …). Para los servicios que requieran un POST o un PUT es aconsejable también proporcionar un esquema para especificar el formato de la respuesta. Describir como nuestro servicio ha de ser invocado, mediante un documento WSDL/WADL o simplemente HTML.
27
28