Patrones y buenas prácticas en SOA/REST Software como Servicio y Distribuido 2010/2011 Diego Sevilla Ruiz DITEC Facultad de Informática Murcia, octubre de 2010 Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 1 / 42
Índice 1 Introducción 2 Patrones SOA/REST 3 Caché memcached 4 BBDD NoSQL 5 MapReduce 6 Arquitecturas reales basadas en REST Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 2 / 42
Índice 1 Introducción 2 Patrones SOA/REST 3 Caché memcached 4 BBDD NoSQL 5 MapReduce 6 Arquitecturas reales basadas en REST Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 3 / 42
Introducción Se verán usos avanzados de la arquitectura REST Se compararán con los enfoques más tradicionales Esta arquitectura permite escalar mucho más que las tradicionales Adiós a las BBDD relacionales y a las formas normales :) El uso de cachés y de programación funcional es fundamental Se verá Memcached y MapReduce Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 4 / 42
Resumen de REST Todo es un recurso (de conjunto o de elemento) Los recursos se identifican con URIs Uso de los verbos HTTP (CRUD) para obtener y modificar los recursos Importancia de los tipos MIME (microformatos) El estado se incluye en el recurso HATEOAS: Hypermedia as the Engine of Application State 1 1 http: //roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven, http://en.wikipedia.org/wiki/hateoas. Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 5 / 42
Índice 1 Introducción 2 Patrones SOA/REST 3 Caché memcached 4 BBDD NoSQL 5 MapReduce 6 Arquitecturas reales basadas en REST Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 6 / 42
Patrones SOA/REST Basada en la charla de Cesare Pautasso 2 La idea: Los conceptos de REST son relativamente sencillos Sin embargo, realizar buenos servicios basados en REST no es sencillo Se verán patrones y anti-patrones 2 REST-Inspired SOA Design Patterns (and Anti-Patterns), http://www.infoq.com/presentations/some-rest-design-patterns. Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 7 / 42
Metodología de diseño REST 1 Identificar los recursos que se exponen como servicios 2 Modelar las relaciones (contenido, referencia) entre los recursos con enlaces (Nótese cómo esto se acerca al metamodelado que hemos visto) 3 Definir URLs amigables para los recursos 4 Comprender qué significa hacer GET, POST, PUT y DELETE a cada recurso (y si se permite o no) 5 Diseñar y documentar las representaciones de los recursos (JSON, XML, microformatos, etc.) 6 Implementar y hacer el deployment en un servidor web 7 Probar con un browser Dimensiones de trabajo Recursos y Representaciones Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 8 / 42
Metodología de diseño REST 1 Identificar los recursos que se exponen como servicios 2 Modelar las relaciones (contenido, referencia) entre los recursos con enlaces (Nótese cómo esto se acerca al metamodelado que hemos visto) 3 Definir URLs amigables para los recursos 4 Comprender qué significa hacer GET, POST, PUT y DELETE a cada recurso (y si se permite o no) 5 Diseñar y documentar las representaciones de los recursos (JSON, XML, microformatos, etc.) 6 Implementar y hacer el deployment en un servidor web 7 Probar con un browser Dimensiones de trabajo Recursos y Representaciones Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 8 / 42
Ejemplo: Servicio Doodle Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 9 / 42
Uso: Crear un poll POST para crear el poll: POST /pool <options>a, B, C</options> 201 Created Location: /pool/432432 Obtener el poll: GET /pool/432432 200 OK <options>a, B, C</options> <votes href="/vote"/> Se utiliza XML en este caso El recurso se aumenta con el recurso interno En otras representaciones el enlace se escribirá de otra manera iego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 10 / 42
Uso: Crear un poll POST para crear el poll: POST /pool <options>a, B, C</options> 201 Created Location: /pool/432432 Obtener el poll: GET /pool/432432 200 OK <options>a, B, C</options> <votes href="/vote"/> Se utiliza XML en este caso El recurso se aumenta con el recurso interno En otras representaciones el enlace se escribirá de otra manera iego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 10 / 42
Uso: Votar POST para crear el voto: POST /pool/432432/vote <name>diego Sevilla</name> <choice>c</choice> 201 Created Location: /pool/432432/vote/1 Obtener el poll: GET /pool/432432 200 OK <options>a, B, C</options> <votes><vote id="1"> <name>...</name> <choice>c</choice> </vote></votes> Se obtienen todos los votos (se podría haber dejado el enlace) Decisión de implementación (relación contenido... tamaño?) iego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 11 / 42
Uso: Votar POST para crear el voto: POST /pool/432432/vote <name>diego Sevilla</name> <choice>c</choice> 201 Created Location: /pool/432432/vote/1 Obtener el poll: GET /pool/432432 200 OK <options>a, B, C</options> <votes><vote id="1"> <name>...</name> <choice>c</choice> </vote></votes> Se obtienen todos los votos (se podría haber dejado el enlace) Decisión de implementación (relación contenido... tamaño?) iego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 11 / 42
Patrones Resumen Negociación de contenido (Content Negotiation) Permite múltiples clientes, evolución Direccionamiento de entidades (Entity Endpoint) Cómo se nombran? Redirección de entidades (Entity Redirection) La redirección permite el balanceo de carga, tolerancia a fallos, etc. Capacidad de invocación idempotente (Idempotent Capability) Al igual que en el web, se debe perseguir esta cualidad (estilo funcional) Contrato uniforme (Uniform Contract) Uso de métodos fijos Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 12 / 42
Patrón Contrato uniforme Construir APIs liga al cliente y al servidor Causa acoplamiento cuando las aplicaciones evolucionan Un cliente tiene que conocer múltiples APIs de distintos proveedores de servicios Solución: Ofrecer un interfaz uniforme (p. ej. verbos de HTTP) que oculte las particularidades de cada servicio Ventajas: Abstracción de servicios, loose coupling, Reusabilidad, Composición de servicios, etc. Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 13 / 42
Patrón Contrato uniforme (ii) POST vs. GET vs. PUT GET es una operación de sólo lectura POST es de modificación (por eso los browsers nos preguntan si reenviar la petición) Cómo se crean los recursos? PUT /recurso/<id> Y si está repetido? GUID por parte del cliente? POST /recurso 301 Moved Permanently Location: /recurso/<id> Tiene el problema de que no es idempotente (duplicación en caso de fallo en las comunicaciones) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 14 / 42
Patrón Redirección de recursos HTTP soporta de forma nativa la redirección con códigos 3xx: GET /old/x 301 Moved Permanently Location: /new/y GET /new/y 200 OK También se puede devolver el código 307 (Temporary Redirect) Se puede usar para balanceo de carga Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 15 / 42
Patrón Direccionamiento de recursos Cómo reutilizar servicios (URLs) dentro de la fachada de los servicios? El «interfaz» ahora es el enlazado de recursos El reuso se hace a nivel de recursos Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 16 / 42
Patrón Direccionamiento de recursos (ii) Ofrecer todos los recursos reutilizables a través de «servicios» El enlazado hace que se puedan reutilizar en otros sitios Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 17 / 42
Patrón Direccionamiento de recursos (iii) Diseño de URIs Preferir nombres a verbos GET /recurso/id=89?action=delete URLs cortas DELETE /recurso/66 Preferir URLs con parámetros posicionales en vez de pares clave/valor No usar postfijos con el tipo (p. ej..xml,.json) Rompen la negociación de contenido (se verá después) Las URLs no deben cambiar Usar redirección si se necesita Cuidado: Los patrones de URIs crean dependencia entre cliente y servidor (son como APIs) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 18 / 42
Patrón Negociación de contenido Cómo soportar diferentes clientes? Versiones Capacidades Esperanzas De una forma evolutiva? Solución: Especificar el versionado y las características en base a media types Microformatos (curioso que el autor no lo mencione) Ventajas: Loose Coupling, mayor interoperabilidad, etc. Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 19 / 42
Patrón Negociación de contenido (ii) No requiere del uso de más mensajes: GET /recurso Accept: text/html, application/json 200 OK Content-type: application/json (Respuesta 406 si no se puede enviar ningún tipo requerido) Se pueden utilizar especificadores de calidad para especificar preferencias: Accept: text/html;q=0.1, application/json;q=0.9 También en diferentes dimensiones: Accept-Language, Accept-Encoding, Accept-Charset, etc. Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 20 / 42
Patrón Capacidad de invocación idempotente Cómo protegerse de fallos de envío de mensajes en sistemas distribuidos? Al perderse el mensaje de vuelta se envía dos veces la petición Solución Usar ESB/MOM (ofrece envío de mensajes con recuperación de fallos) Diseñar las peticiones como idempotentes (filosofía REST) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 21 / 42
Patrón Capacidad de invocación idempotente (ii) Idempotente vs. No seguro Las peticiones idempotentes se pueden enviar varias veces sin problemas: GET /libro/x PUT /pool/y DELETE /libro/z Si algo falla, la petición se puede reintentar Las respuestas «seguras» son aquellas que no modifican el estado del servidor (GET) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 22 / 42
Patrón Capacidad de invocación idempotente (iii) Idempotente vs. No seguro Las peticiones que modifican el estado son «no seguras»: withdraw(account1, 200) deposit(account2, 200) POST /clients Si algo falla en el último caso, harán falta mecanismos adicionales de reconciliación de estado (con identificadores, etc.) A veces los APIs se pueden diseñar de manera que sean idempotentes: B = getbalance(); // Idempotente B = B + 200; // Local setbalance(b); // Idempotente Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 23 / 42
Patrón Capacidad de invocación idempotente (iv) Concurrencia Qué pasa si otro cliente accede mientras tanto? Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 24 / 42
Patrón Capacidad de invocación idempotente (v) Concurrencia optimista Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 25 / 42
Antipatrones Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 26 / 42
Antipatrones HTTP como túnel GET /api?method=addcustomer&name=diego GET /api?method=deletecustomer&id=42 Todo sobre GET Ventaja: Se puede usar fácilmente desde un browser Inconvenientes: GET se debe usar para peticiones idempotentes (caché, tolerancia a fallos, etc.) Algunos sistemas tienen limitaciones en el tamaño de la URL Todo sobre POST Ventaja: Se puede enviar cualquier tamaño de datos (es lo que utiliza SOAP) Inconvenientes: POST no es idempotente ni se le puede hacer caché POST /servicio/endpoint /servicio/endpoint es un recurso? Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 27 / 42
Índice 1 Introducción 2 Patrones SOA/REST 3 Caché memcached 4 BBDD NoSQL 5 MapReduce 6 Arquitecturas reales basadas en REST Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 28 / 42
Caché memcached Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 29 / 42
Caché memcached (ii) 1 function get_foo ( foo_id ) foo = memcached_get (" foo :". foo_id ) 3 return foo if defined foo 5 foo = fetch_ foo_ from_ database ( foo_id ) memcached_set (" foo :". foo_id, foo ) 7 return foo end Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 30 / 42
Caché memcached (iii) $ telnet localhost 11211 2 Trying 127.0.0.1... Connected to localhost. 4 Escape character is ^]. get foo 6 VALUE foo 0 2 hi 8 END Protocolo sencillo basado en texto Representación de valores como string ( imágenes?) Se pueden usar varios servidores ( sincronización?) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 31 / 42
Índice 1 Introducción 2 Patrones SOA/REST 3 Caché memcached 4 BBDD NoSQL 5 MapReduce 6 Arquitecturas reales basadas en REST Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 32 / 42
BBDD NoSQL MongoDB, CouchDB Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 33 / 42
CouchDB Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 34 / 42
CouchDB (ii) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 35 / 42
CouchDB (iii) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 36 / 42
CouchDB (iv) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 37 / 42
CouchDB (v) Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 38 / 42
CouchDB (vi) $ curl - XPOST - HContent - type : application / json localhost :5984/ watches -- data {" brand " : " Seiko ", " model ":" skx007k1 " } 2 {" ok ": true," id ":" cfe517a13ace79a06fd71780580006d5 "," rev ":"1 - d2908ae2339164e45c37f782ce081016 "} 4 $ curl - XGET - HContent - type : application / json localhost :5984/ watches / cfe517a13ace79a06fd71780580006d5 {" _id ":" cfe517a13ace79a06fd71780580006d5 "," _rev ":"1 - d2908ae2339164e45c37f782ce081016 "," brand ":" Seiko "," model ":" skx007k1 "} Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 39 / 42
Índice 1 Introducción 2 Patrones SOA/REST 3 Caché memcached 4 BBDD NoSQL 5 MapReduce 6 Arquitecturas reales basadas en REST Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 40 / 42
Índice 1 Introducción 2 Patrones SOA/REST 3 Caché memcached 4 BBDD NoSQL 5 MapReduce 6 Arquitecturas reales basadas en REST Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 41 / 42
Referencias C. Pautasso Some REST Design Patterns (and Anti-Patterns) http://www.jopera.org/docs/talks/2009/rest-patterns InfoQ (varios autores) InfoQ Explores REST http://www.infoq.com/resource/minibooks/ emag-03-2010-rest/en/pdf/rest%20emag.pdf S. Tilkov REST Anti-Patterns y REST doubts http://www.infoq.com/articles/rest-anti-patterns http://www.infoq.com/articles/tilkov-rest-doubts M. Paternostro, K. Hussey Building RESTful Java Applications with EMF http://www.slideshare.net/kenn.hussey/ building-restful-java-applications-with-emf Diego Sevilla Ruiz (DITEC Facultad de Informática) Patrones y buenas prácticas en SOA/REST Murcia, octubre de 2010 42 / 42