Conceptos Avanzados de Internet Web Services (III): REST PDF

Conceptos Avanzados de Internet Web Services (III): REST REST  REST define unas guías o restricciones para definir Servicios Web que recogen los principios que han hecho que la Web haya llegado a tener tanto éxito  Algunos objetivos de REST son:...

Conceptos Avanzados de Internet Web Services (III): REST REST  REST define unas guías o restricciones para definir Servicios Web que recogen los principios que han hecho que la Web haya llegado a tener tanto éxito  Algunos objetivos de REST son:  Escalabilidad  Generalidad de las interfaces  Interfaces cliente-servidor intuitivas y sencillas (GET + recurso, PUT + recurso, etc.)  Independencia en el desarrollo de componentes  Se puede modificar el código sin que afecte al funcionamiento del servicio (si se mantiene el interfaz)  Se pueden añadir nuevos recursos (no afecta a los existentes)  Mejorar latencia  Permite el uso de cachés y balanceo de carga. 2 Fundamentos de REST REST: Restricciones / Principios arquitecturales  Un Servicio Web REST debe cumplir estas restricciones: o Cliente-Servidor o Sistema por capas o Caché o Comunicación sin estados o Interfaz uniforme o Identificación de recursos o Manipulación de recursos a través de representaciones o Mensajes autodescriptivos o HATEOAS (Hypermedia As The Engine Of Application State) o Code On Demand (opcional)  REST no es la solución ideal para todo tipo de aplicación, se deben estudiar otras alternativas  REST no es una religión! A veces puede ser interesante saltarse una restricción si una aplicación en concreto lo requiere  Aunque el WS no se considere REST se beneficiará de las ventajas asociadas a otras restricciones  Niveles de madurez, del 0 (mínimo) al 3(máximo) según cumplimiento de REST  Nota: REST no obliga a usar HTTP, pero se suelen usar juntos 3 Fundamentos de REST Restricción: Interfaz uniforme  Principal restricción de REST  Identifica qué se puede hacer con los recursos  Se va a justificar la necesidad de esta restricción siguiendo el modelo de madurez de Richardson (definido posteriormente a REST), define en que medida un API se puede considerar RESTful. Asumimos que se usa el protocolo HTTP para las comunicaciones Nivel 3: Controles hipermedia (hiperenlaces) – Totalmente REST Nivel 2: Verbos HTTP – Usado en la mayor parte de WS REST ++ Nivel 1: Uso de recursos Nivel 0: RPC – Nada REST 4 Nivel 0 de Richardson (nada REST)  Todas las peticiones se dirigen al mismo endpoint (URI), contienen nombre de operación y argumentos de entrada  Ejemplo petición y respuesta del servidor: Cliente POST /endpoint Accept: application/xml  Lista de operaciones disponibles: leeEdad, cambiaEdad, leeEmail, cambiaEmail, despideEmpleado, etc.  Muchas operaciones, cada una con distintos Servidor argumentos de entrada y de salida  Complejo de manejar por un programador! HTTP/1.1 200 OK  Consultar todas las operaciones en documentación Content-Type: application/xml  En nivel 0 se ignora completamente HTTP Content-Lenght: 36  Se podría haber utilizado GET en lugar de POST (se ignora el método HTTP). Un GET para escribir!!! 25 5 Nivel 1 de Richardson  Añade el uso de recursos:  Cada recurso tiene su propia URI a la que se envían las peticiones  Ejemplo petición y respuesta del servidor: Cliente POST /emp/99 Accept: application/xml  APIs siguen sin considerarse RESTful  Mejora muy pequeña respecto al nivel 0: se puede especificar sobre qué recurso Servidor ejecutar la operación HTTP/1.1 200 OK Content-Type: application/xml Content-Lenght: 36 25 6 Nivel 2 de Richardson  Se puede considerar que es REST (muchas APIs RESTful son de nivel 2)  Se usan los métodos de HTTP (HTTP verbs)  GET para leer, PUT para escribir, DELETE para borrar…  En las peticiones y respuestas se mandan representaciones de los datos.  Estado actual de un recurso, en una notación en concreto (JSON, XML, etc.) Cliente GET /emp/99  Ventajas: Accept: application/xml  API más sencillo  Se determinan los recursos y su estructura  Las operaciones sobre ellos son intuitivas: ¿ Servidor  Pregunta: ¿Cómo cambiar la edad? HTTP/1.1 200 OK  Se usa HTTP: Content-Type: application/xml  Permite uso de cachés. Se almacenan representaciones por si un Date: Wed, 12 Oct 2016, 16:30 recurso vuelve a pedirse más adelante Content-Lenght: 74  Código de respuesta da información útil (HTTP ahora es protocolo de aplicación)  P.ej. 201 = recurso creado, 404 = recurso no encontrado, 200 = respuesta estándar para peticiones correctas 25 Representación correspondiente al recurso empleado 99, [email protected] el 12 de octubre de 2016, en formato XML 7 Pregunta. REST: Modificar un campo de una representación  Un servidor tiene un recurso /empleado/125. La representación del recurso es: 25 [email protected]  ¿Con cual de las siguientes opciones cambiarías la edad a 26 años (manteniendo el resto de campos igual)? A) 1.GET /empleado/125 - 2.Modificar edad en la representación obtenida- 3.PUT /empleado/125 B) PUT /empleado/125 mandando una representación con solo la edad Pulsa sobre el código QR o escanéalo para responder ¿Te imaginas cómo se cambia el email? REST es intuitivo para un desarrollador 8 Nivel 3 de Richardson  Añade hiperenlaces mediante HATEOAS (Hypermedia As The Engine Of Application State)  Se dan enlaces a operaciones permitidas, no se permiten otras  Se estudiará más adelante GET /producto/25 Accept: application/json HTTP/1.1 200 OK Content-Type: application/json Date: Wed, 12 Oct 2016, 16:35 Content-Lenght: 74 {“nombre” : “Galaxy Note 7”, “precio”: 800, “descripción” : “es la bomba!”, enlace a la lista de productos, enlace para comprar el producto } 9 Restricción: Interfaz uniforme (cont.)  La Interfaz Uniforme se divide en 4 restricciones a la interfaz cliente-servidor (con conceptos que acabamos de ver) o Identificación de recursos o URIs /emp/35 o Manipulación de recursos a través de representaciones o XML, JSON, etc. {“nombre”: “Pedro”, “edad”:25 …} o Mensajes auto-descriptivos o Método HTTP + URI o APIs son fáciles de manejar o HATEOAS (Hypermedia As The Engine Of Application State) o Hiperenlaces 10 Fundamentos de REST  Interfaz uniforme: Mensajes auto- descriptivos  Los mensajes deben contener información suficiente para determinar cómo se deben procesar (qué método invocar) e interpretar (qué efecto van a tener).  Para determinar qué método (código) se invoca se suele usar:  Método HTTP (GET, PUT, POST, DELETE…)  URI  Tipo de datos solicitado o enviado (imagen, XML, JSON…) PETICIÓN: SERVIDOR JAVA GET /ejemplo.com/empleado/100 HTTP/1.1 @GET Accept: application/json @Path(“/empleado/{id}”) @Produces(“application/json”) SERVIDOR Python (Flask) public Empleado getEmpleado(@PathParam (“id”) String id) { @app.route(‘/empleado/', methods =['GET']) …. def get_empleado(id): } Observad como se usan decoradores (@decorador) en el servidor para que sepa que método ejecutar 11 Fundamentos de REST Interfaz uniforme: Representaciones de recursos  Representación = estado actual de un recurso {“empleado”: { “nombre”: “Pedro”, {“empleado”: { “nombre”: “Pedro”, “edad”: 25, “edad”: 25, CAMBIA TELEFONO “telefono”: 968012345 “telefono”: 623456789 } } } }  Un mismo recurso puede tener representaciones en distintos formatos/lenguajes Pedro  P. ej. XML o JSON 25  Cabecera Accept (y Content-Type) 968012345  Para solicitar un formato (y enviar datos) 12 Fundamentos de REST Operaciones CRUD en REST  CRUD = Create, Read, Update, Delete.  Normalmente los datos se ordenan en colecciones de datos y se suele trabajar con ellos de la siguiente forma: (ejemplo para una colección de empleados) URI GET PUT POST DELETE emp/ Lee lista emp Sobrescribe Añade nuevo ---- lista emp. empleado emp/{id} Lee Añade/Sobre ---- Borra empleado id escribe empleado empeado id  Obligatorio que cada método HTTP se comporte tal y como definen las RFCs (GET = leer, etc.) y devuelva código de estado y cabeceras indicadas por la RFC  Opcionalmente podemos permitir o no ciertas operaciones, a decisión del programador  Borrar o sobrescribir colecciones ? (ver si es peligroso)  Crear nuevos ítems usando PUT? 13 POST vs PUT para crear/modificar recursos  Ambos mandan la representación del objeto a escribir  POST se dirige a la colección, no indica el identificador (normalmente) y deja al servidor asigne un identificador y una URI al recurso POST /emp  El servidor elige un id (podría generar otros campos nuevos si lo creyera Accept: application/json conveniente, p.ej. calcular el coste de un pedido a partir de los productos Content-Type: Application/json que incluye) y crea una URI a partir del id …  El código 201 indica al cliente que ha creado un nuevo recurso  Indica al cliente la nueva URI con una cabecera location donde se encuentra {“nombre” : “Pedro”, el recurso  Cabecera Location siempre acompaña a 201 “ciudad”: “Cartagena”, “edad”: 25  En el cuerpo se puede devolver debe devolver un mensaje informativo (a), de acuerdo a la RFC. A veces se devuelve una representación del recurso } (b).  Ventaja POST para crear: el servidor elige el id y evita conflictos de ids HTTP/1.1 201 Created repetidos (aunque ids sean menos intuitivos) Content-Type: application/json Date: Wed, 12 Oct 2016, 16:30 (b) HTTP/1.1 201 Created Location: /emp/4f39a0 Content-Lenght: 83 Content-Type: application/json (a) Date: Wed, 12 Oct 2016, 16:30 Location: /emp/4f39a0 {“id”: 4f39a0, Content-Lenght: 57 “nombre” : “Pedro”, “ciudad”: “Cartagena”, {“status”: “ok”, “edad”: 25 “message”:”new resource created”} } 14 POST vs PUT para crear/modificar recursos  PUT se dirige a la URI del recurso, exista o no (si no existe lo crea, si el servidor permite esa opción) PUT /emp/25 Accept: application/json  La representación que se manda se usa para escribir el recurso. Content-Type: Application/json  El código 201 indica al cliente que ha creado un nuevo recurso (a) …  El código 200 indica al cliente que el recurso se ha modificado (ya existía) y devuelve una representación con el estado de la operación (b) {“id”: “25”, “nombre” : “Pedro”,  El código 204 indica que se ha modificado y que no se devuelve cuerpo en la respuesta (c) “ciudad”: “Cartagena”,  Indica al cliente la nueva URI con una cabecera location donde se encuentra “edad”: 25 el recurso }  En el cuerpo se puede devolver (a) una representación del recurso o (b) un mensaje informativo o incluso devolver el cuerpo vacío: en cualquier caso el recurso se puede encontrar mediante la cabecera location HTTP/1.1 200 OK HTTP/1.1 201 Created (a) Content-Type: application/json (b) (c) Content-Type: application/json HTTP/1.1 204 No content Date: Wed, 12 Oct 2016, 16:30 Date: Wed, 12 Oct 2016, 16:30 Content-Type: application/json Location: /emp/25 Location: /emp/25 Se crea /emp/25 Date: Wed, 12 Oct 2016, 16:30 Content-Lenght: 57 Content-Lenght: 19 {“id”: 25, Location: /emp/25 “nombre” : “Pedro”, Content-Lenght: 57 “ciudad”: “Cartagena”, {“status”: “ok”, {“status” : “ok”} “message”: ”resource “edad”: 25 } modified”} 15 Operaciones RPC vs REST  Operaciones para un empleado:  API RPC, API REST (GET, PUT, POST, DELETE) + URI  leeDirección(int id_empleado)  cambiaDirección(int id_empleado, String dir) vs {“id” : 25,  leeEdad(int id_empleado) “dirección”: “Carlos III, 35”,  darDeBaja(int id_empleado)  Etc., etc. “email”:”….”, … “estado”: “Alta”…}  Para cambiar la dirección de un empleado  Para cambiar la dirección de un empleado (Suponiendo que se sabe el id del empleado) (Suponiendo que se sabe el id del empleado)  Consulta la extensa documentación del API  Lee representación del recurso (GET /emp/25)  Llama a cambiaDirección(id) – con POST  Modifica campo dirección (cliente en local)  Para dar de baja a un empleado  Manda nueva representación (PUT /emp/25)  Consulta la extensa documentación del API  Para dar de baja a un empleado  Llama a darDeBaja(id)  Igual que antes pero modifica el campo estado  Idem para resto de métodos  Idem para resto de métodos  No hay que conocer las (muchísimas) operaciones, solo los recursos (URIs* y estructura de datos) *Con HATEOAS no es necesario conocer las URIs 16 Fundamentos de REST Borrar un recurso  Se utiliza DELETE para borrar un recurso (hacer que desaparezca totalmente de la base de datos)  En caso de éxito, se devuelve 200 o 204 según si las respuesta incluye un mensaje de esto en el cuerpo o no  En caso de error 4xx – según si el cliente ha hecho mal la petición (400), no se ha autenticado, no tiene permiso, etc. o 5xx (si falla el servidor). Códigos de error también podrían darse con otros métodos HTTP DELETE /emp/25 Accept: application/json … HTTP/1.1 200 OK HTTP/1.1 204 No content Content-Type: application/json Date: Wed, 12 Oct 2016, 16:30 Date: Wed, 12 Oct 2016, 16:30 Content-Lenght: 56 … {“status” : “ok”, “message”:“resource deleted”} 17 Operaciones no CRUD  Si la operación no corresponde a leer, escribir o borrar → se puede usar POST.  Ejemplo propuesto por el creador de REST: Arrancar máquinas virtuales (VM).  Problema: Se configura una máquina virtual en /vm/155 (RAM, núcleos, etc.). ¿Cómo se hace para que comience a ejecutarse?  POST /vm/155/run > Arranca la maquina virtual. Equivalente a pulsar un botón y encenderla  Automáticamente se modifica el estado de la VM (arrancando) > servidor redirecciona a /vm/155 para consultar nuevo estado  Se ha devuelto 303 Redirect ya que se ha redireccionado a otro recurso existente. Si otros recursos no cambiaran se podría devolver un 200 (o un 201 si se creara un recurso, 204 si no hubiera cuerpo, etc.). POST /vm/155/run GET /vm/155 Accept: application/json Accept: application/json … … HTTP/1.1 303 Redirect HTTP/1.1 200 OK Content-Type: application/json Content-Type: application/json Location: /vm/155 Date: Wed, 12 Oct 2016, 16:30 Date: Wed, 12 Oct 2016, 16:30 Content-Lenght: 100 Content-Lenght: 100 … … {“id” : 12345, {“status” : “ok”, “OS”: “Linux”, “state”: “booting”, ….} “message”:“VM running, check given URI to get the Si 1 segundo después se vuelve a leer el estado seguiría current state of the VM”} siendo booting, si se lee un minuto después sería booted, etc. 18 Otras restricciones de REST  Un Servicio Web REST debe cumplir estas restricciones: o Cliente-Servidor o Sistema por capas o Caché o Comunicación sin estados o Interfaz uniforme o Identificación de recursos o Manipulación de recursos a través de representaciones o Mensajes autodescriptivos o HATEOAS (Hypermedia As The Engine Of Application State) o Code On Demand (opcional) 19 REST: Restricción Cliente-Servidor  Se usa un modelo Cliente-Servidor que permite separar al servicio de los consumidores:  Componentes del cliente  Componentes del servidor  Interfaz cliente-servidor  Objetivos perseguidos (al aplicarse junto a otras restricciones):  Reusabilidad (del servicio)  Capacidad de evolución  Cliente y servidor evolucionan de forma separada, sin afectar a su funcionamiento  Escalabilidad  En REST se persigue simplificar los componentes del servidor a costa del cliente. Cuantos menos recursos consuma un servidor más fácil será atender a más clientes sin sobrecargarse (y por tanto necesitar más servidores)  Portabilidad  Independencia del sistema operativo, lenguaje de programación 20 Fundamentos de REST REST: Sistema por capas  Un sistema REST puede componerse de varias capas (que no tienen porqué conocerse entre ellas) y debe funcionar correctamente haya una o más capas:  Capas: Cliente, Proxies, Gateways/proxies inversos, Servidor, etc.  Se desconocen entre ellas  Pueden actuar como cachés (cliente, proxies, gateways), repartidores de carga (Gateways), implementar mecanismos de seguridad…  Objetivos: Mejorar rendimiento, escalabilidad, seguridad… Instalaciones proveedor Instalaciones empresa del servicio El servicio debe funcionar correctamente haya capas intermedias o no Gateway Clientes Proxy / Proxy inverso Servidores 21 Fundamentos de REST REST: Caché  Datos en respuestas deben ser marcados como cacheables o no cacheables  Con caché mejora el rendimiento (latencia) pero se podrían mandar datos obsoletos  Ejemplo:  Dato crítico de un solo cliente -> No cacheable  Dato compartido de acceso frecuente -> Cacheable (público, también en proxys y gateways) Caché Proxy Gateway Caché de aplicación Cachés → local cache cache (peor caché, no HTTP) Un usuario Usuarios Usuarios local intranet Internet 22 Fundamentos de REST REST: Caché (II)  Cache-Control  Configuración de caché (dónde y cómo almacenar) Cache-Control: public, max-age=3600 Cache-Control: no-store  Etag (servidor) + If-None-Match (cliente)  Servidor envía una firma (hash) del recurso  Si cambia recurso cambia la firma  Cliente solicita recurso sólo si ha cambiado  Last-Modified (servidor) + If-Modified-Since (cliente)  Según fecha de modificación GET ejemplo.com/emp/50 GET ejemplo.com/emp/50 … If-none-match: “c9a544f026a2b129” … HTTP/1.1 200 OK Etag: “c9a544f026a2b129” HTTP/1.1 304 Not modified … Etag: “c9a544f026a2b129” … {“nombre”: “Pedro”, “Edad”: 25… 23 Fundamentos de REST REST: Restricción “Comunicaciones sin estados / Stateless” (I)  No se debe almacenar información sobre el estado de una sesión entre un cliente y servidor  El resultado de una petición no debe verse afectado por las peticiones anteriores realizadas o por el cliente o sobre el recurso (salvo que se haya modificado el recurso!) GET /empleados?edad_minima=30 No debe GET /empleados?localidad=Cartagena afectar  Por lo tanto, cada petición debe llevar toda la información necesaria para que el servidor la pueda entender correctamente GET /empleados?edad_minima=30&localidad=Cartagena  Es el cliente el que debe almacenar el estado, no el servidor 24 Fundamentos de REST REST: Restricción “Comunicaciones sin estados / Stateless” (II)  Objetivos  Visibilidad por parte de intermediarios (cacheado, balanceo de carga, seguridad, etc.)  Los dispositivos intermedios entienden las comunicaciones cliente-servidor y pueden realizar su tarea sin preocuparse por estos almacenado en otros dispositivos  Fiabilidad  Facilidad para recuperarse ante errores (si cae un servidor no importa ya que no almacena estado de las sesiones de los clientes)  Escalabilidad  Al no tener que almacenar el estado para cada cliente se facilita la escalabilidad. Se pueden lanzar peticiones a granjas de servidores y que cualquiera de ellos las procese  Desventajas  Pequeña degradación de la eficiencia al tener que mandarse más datos en cada petición  Query params, tokens para seguridad (en cabeceras), datos JSON/XML, etc.  Pérdida de control por parte del servidor. El funcionamiento del servicio depende de que los clientes estén implementados correctamente  Prueba para comprobar esta restricción  Reiniciar el servidor y comprobar, tras arrancar, si el servicio sigue funcionando  No se ha debido perder ningún dato del cliente (porque no los hay en el servidor) 25 Fundamentos de REST REST: Estado de los recursos vs estado de la aplicación  Que no haya estado en las comunicaciones (sesión) no implica que no haya ningún tipo de estado:  Estado de los recursos:  Valor de los recursos (imagen, empleados, etc.)  Almacenado en el servidor (almacenamiento permanente, en base de datos)  Estado de la aplicación:  Estado del cliente, almacenado en el cliente  Ejemplo en la Web: hacer una búsqueda en Google https://www.google.es/search?q=upct&start=40 En navegador solo podemos estar en un página a la vez > Vamos a considerar que la página en la que estamos es el estado del cliente Si hacemos una búsqueda tendremos páginas con 10 resultados (0..10 > P1, …, 40..50 > P5). Pedir desde el resultado 40 (página 5): https://www.google.es/search?q=upct&start=40 Es en la propio navegador (o un cliente de un servicio web) donde está este tipo de estado. Al servidor le da igual si hemos visto las páginas anteriores, solo da la página que le pidamos. 26 Fundamentos de REST REST: HATEOAS  HATEOAS (Hypermedia As The Engine Of Application State)  Es la restricción más ignorada (compleja) pero también la que mayores posibilidades ofrece  Hipermedia:  Hipertexto: Texto con (hiper)enlaces a otros textos  Hipermedia: Término más genérico en el que además de texto puede haber imágenes, audio o video  Propósito:  Al igual que en la Web busca que el servidor ofrezca una serie de enlaces y el cliente “navegue” a través de ellos  El servidor dice al cliente qué puede hacer en cada momento a través de enlaces (links) → El servidor controla el estado de la aplicación (estado del cliente)  En cada mensaje de respuesta del servidor las representaciones de los recursos incluyen enlaces para la próxima petición  Las representaciones devueltas contienen el nuevo estado de la aplicación 27 Fundamentos de REST REST: Ejemplo HATEOAS (I)  Ejemplo: Una aplicación móvil para manejar la cuenta del banco  Petición con saldo positivo: GET /cuentas/12345 HTTP/1.1 … HTTP/1.1 200 OK 12345 1000  Permite operaciones que impliquen ingresar o sacar dinero, incluso cerrar la cuenta 28 Fundamentos de REST Pregunta: Ejemplo banco con HATEOAS, ¿Qué ocurre con una cuenta en negativo?  Si tenemos la cuenta en números rojos y el banco no nos permite deberle más dinero: 1. ¿Qué operaciones nos dejará hacer? ¿Ingresos? ¿Transferencias? ¿Dar de baja? 2. ¿Qué ocurre si intentamos hacer una operación que no está en los enlaces que devuelve el servidor? ¿Es correcto hacerla?¿No deberíamos? 29 REST: Ejemplo HATEOAS (II)  Ejemplo: Una aplicación móvil para manejar la cuenta del banco  Petición con saldo negativo: GET /cuenta/12345 HTTP/1.1 … HTTP/1.1 200 OK 12345 -100  Ahora sólo permite ingresar dinero El servidor controla el estado de la aplicación (en el cliente) 30 Fundamentos de REST REST: Links en HATEOAS En JSON: {“links”:[ {“rel” : “ingreso”, “href” : “/cuentas/12345/ingresos”}, {“rel” : “transferencia”, “href” : “/cuentas/12345/transferencias”} ]} o bien (más común) {“links”: [ {“ingreso”: “http://example.com/customers/771/ingresos”}, {“transferencia”: “http://example.com/customers/771/ transferencia”}, ]  Links  Tipos de enlaces entre recursos predefinidos (y creciendo) http://www.iana.org/assignments/link-relations/link-relations.xml  Se pueden crear nuevas relaciones para cubrir las necesidades de una aplicación en particular (p.ej. ingreso, retirada, transferencia, cierre)  El cliente debe entender su significado y procesarlas correctamente  En caso de no conocer alguna relación la ignora (pero sigue funcionando)  Los enlaces deben incluir la URI y opcionalmente: método, tipo de datos (ejemplo: application/vnd.upct.formulario-para-transferencia + json) 31 Fundamentos de REST REST: HATEOAS, ejemplo relación next  Se hace una petición al servidor sobre un conjunto de datos pero éste no devuelve todo el conjunto  Tipo de relación predefinido “next”: Links de la lista de productos headphones $16.99 Links a un producto en … concreto