‘hozors Servicios web (2): Qué es REST?| Teo dja Continuando con el tema de los servicios web, en este post voy a hacer una Introduccién a REST. Os prometo que este seré breve (para mis estandares) y en préximos post nos metemos més en detalle. Lo primero es aclarar que REST no es una tecnologia, ni siquiera una arquitectura, sino una familia de arquitecturas. Cualquier arquitectura de servicios distribuidos que cumpla con una serie de requisitos se puede considerar como una arquitectura REST. Estos requisites o propiedades son los siguientes: No se publican servicios RPC. En arquitecturas REST, los servicios no publican un conjunto arbitrario de métodos u operaciones. Por ejemplo, en REST no podemos publicar una interfaz "IGestion€mpleados” con métodos "addEmpleado”, "removeEmpleado” o "buscarEmpleadosEn€dadDeJubilacion”. En REST lo que se publica son recursos, Un recurso se puede considerar como una entidad que representa un concepto de negocio que puede ser accedido publicamente, Un ejemplo de recurso seria simplemente "EmpleadosDeLaEmpresa” y otro podria ser “Empleado numero 33” Cada recurso, como buena entidad que se precie, y de acuerdo a los principios de 00, posee un identificador nico y global, que lo distingue de cualquier otro recurso, aunque ambos tuvieran exactamente los mismos datos. En el caso de "Empleado 33”, este seria diferente de "Empleado 40", aunque tuvieran el mismo nombre, sueldo, ete. Cada recurso posee un estado interno, que no puede ser accedido directamente desde el exterior. Lo que si es accesible desde el exterior es una o varias representaciones de dicho estado. Por representacién se entiende un formato de datos concreto usado para la transferencia de una copia del estado piblico del recurso entre el cliente y el servidor. La implementacién del recurso decide que informacién es visible o no desde el exterior, y que representaciones de dicho estado se soportan. Una representacién de “Empleado 33” podria ser un documento XML con la informacién accesible de este, Otra representacién seria un documento HTML y otra podria ser un JSON. No sélo podemos representar el recurso como datos estructurados, hay que echarle imaginacién. Podriamos pedir por ejemplo, una representacién en formato imagen PNG del recurso, tal vez esto devolveria una foto del empleado, o un grafico de su productividad o su huella dactilar Sino podemos definir operaciones arbitrarias sobre el recurso, écémo podemos operar con él? En REST todos los recursos comparten una interfaz Unica y Constante, Todos los recursos tienen las mismas operaciones. Las operaciones nos permiten manipular el estado publico del recurso. En un sistema REST tipico se definen cuatro operaciones. CREATE. En esta operacién el cliente manda al servidor una peticién para crear un nuevo recurso. Opcionalmente el cliente puede mandar una representacién de! estado inicial de este recurso. El servidor responde con el identificador global del nuevo recurso. DELETE. En esta operacién el dliente elimina un recurso del servidor. El cliente necesita saber el identificador del recurso, READ, Con esta operacién el cliente puede leer una representacién del estado de un recurso, identificado con su identificador global. El cliente puede especificar que tipos de representaciones entiende. Aqui lo que ocurre realmente es que se copia el estado del recurso en el servidor y se pega en el cliente. Ambas copias del estado no se mantiene sincronizadas. El servidor puede cambiar el estado real del recurso y el cliente, de forma independiente, puede modificar su copia local de! estado del recurso, UPDATE. Como el servidor y el cliente tienen una copia diferente del estado, el cliente puede usar esta operacién para sobrescribir o grabar su copia del estado en. el servidor. De esta manera se puede actualizar el estado del recurso con las modificaciones hechas en el cliente. La implementacién del servicio es libre de prohibir alguno de estos métodos para un recurso en concreto. También debe definir el modelo de datos que se va a publicar y que representaciones soporta. Lo que no puede hacer es inventarse operaciones de forma arbitraria. Las operaciones son siempre las mismas. Los distintos recursos se pueden interrelacionar y referenciar entre si mediante sus identificadores globales. Una confusién tipica es pensar que REST no es mas que un CRUD llevado a la web, no seré mi BBDD relacional un sistema REST? No exactamente. Es parecido, pero existen algunas diferencias sutiles e importantes entre un CRUD simple o una BBDD con una arquitectura REST: Al contrario que en un CRUD tipico, como una BBDD, el servidor puede soportar muchas representaciones de un mismo recurso: xml, pdf, png, gif, excel, html, json, texto, comaereas, churros binarios, etc.. Hay pocas BBDD que hagan esto. No penséis que las operaciones REST se limitan a hacer CRUD tradicional, no se trata solo de persistir nuestros cambios. Cuando hacemos un UPDATE, nuestra implementacién del recurso ademas de grabar el estado en soporte persistente, debe hacer otras cosas, como validaciones de negocio o actualizaciones en otros recursos para mantener la consistencia global del sistema. Esto si que se parece a una BBDD con triggers e integridad referencial, pero no es CRUD en el sentido de que no nos limitamos a grabar y ya esta, Una DAO es CRUD, un recurso REST no (excepto en los casos més simples). Los recursos mantiene interrelaciones entre si. La topologia de estas interrelaciones es compleja, puede ser un grafo arbitrario, con ciclos, o un simple arbol. Es més, los recursos de nuestro sistema se pueden interrelacionar con recursos en sistemas de terceras partes, ya que él identificador es Unico y global. Itpe:iteamodeorubiowordpress,com/201Q40728'servicios-web-2-%C2%BF que-es-rest 12‘hozors Servicios web (2): Qué es REST?| Teo dja Algunos estareis pensando: “ZExiste en la actualidad alguna arquitectura REST? Estas cosas tan modernas tardan un tiempo en madurar, y yo no quiero usar una tecnologia que esté verde”, Pues resulta que REST es un enfoque maduro con un claro ejemplo existente en la actualidad: la world wide web, o web a secas. Veamos si la web tiene propiedades REST! La web esta compuesta de recursos, cada pagina web puede considerarse un recurso. Cada recurso tiene un identificador Unico global, que es su URI (0 URL para los antiguos o IRI para los mas modernos). Usando una URL podemos llegar a cualquier recurso en la web. Dada una URI, y mediante él protocolo HTTP, podemos operar sobre estos recursos. La operacién a realizar se especifica mediante el verboHTTP. Mediante cabeceras especiales como Accept o Content-Type se puede espectficar que representaciones entienden el servidor y el cliente y que representacién se usa en un. mensaje concreto para transporta el estado del recurso. El verbo GET hace la operacién READ. El verbo DELETE hace la operacién DELETE, El verbo PUT se usa normalmente para hacer UPDATE El verbo POST se usa normalmente para hacer CREATE Las representaciones a usar se especifican mediante los llamados tipos mime, La mayoria de los tipos mime son estdndares, como xml o json. El usar tipos mime estdndar facilita la interoperabilidad. La aplicacién cliente tipica de la web es el navegador. Los navegadores se dedican a hacer GETs sobre URIs para obtener representaciones de las distintas paginas web. En el caso habitual cada pagina sélo admite una representacién, tipicamente HTML 0 PDF 0 texto plano o imagenes. Pero eso no significa que una misma URI no pudiera soportar distintas representaciones. Lo interesante de todo esto es que la web es un ejemplo perfecto de servicios distribuidos @ nivel global totalmente interoperable (0 casi). La web, y el protocalo HTTP es, una arquitectura REST, La web son servicios REST que en general sélo soportan HTML, Casi cualquier pagina HTML es interoperable con casi cualquier navegador, y casi cualquier pagina HTML puede interoperar (referenciar) con otra pagina HTML construida por un tercero. Es sorprendente que con este claro ejemplo, presente en nuestro dia a dia, llegada la hora de pensar en como hacer servicios web, no se viera lo que tenemos delante de la cara, sino que se inventara algo como SOAP y WSDL. Mmmm, sospechoso. Como veis podemos usar HTTP, URIs y tipos mime, para publicar servicios de datos, no meras paginas, que soporten multitud de representaciones y sean conformes a los, principios REST. A este tipo de servicios de datos es a los que cominmente se llaman servicios REST. Sin embargo aun tengo que contar por qué desde mi punto de vista los servicios REST son mejores que SOAP. Las razones son varias: HTTP es un protocolo que sigue los principios REST, por lo tanto hacer servicios REST es algo que aprovecha toda la infraestructura de la web ya existente: cache, Proxies, firewall, compresién, etc, No se trata de inventar un protocolo y ver como meterlo con calzador para que encaje dentro de HTTP, sino usar el propio HTTP. La posibilidad de usar miltiples representaciones o formatos de datos, de forma natural, es una ventaja indiscutible. No hay que extender ningiin protocolo, 0 limitarse a XML, el protocolo HTTP ya lo soporta de forma natural, Si usamos un poco de imaginacién esto puede ser una caracteristica muy potente. Los servicios REST tienen menor acoplamiento que los servicios basados en SOAP, Esto lo veremos en futuros posts. No necesitamos herramientas complejas, ni montones de cédigo generado e inmantenible. Un simple framework nos basta. Para sistemas sencillos no necesitamos nieso. Una aplicacién AJAX 0 un mévil tienen la capacidad computacional suficiente para actuar como cliente de servicios REST. Es autodescubrible, no se necesita algo como un WSDL, Esto lo veremos también en futuros posts. En el préximo post pienso aplicar de forma més concreta todos estos principios al mundo de las aplicaciones empresariales, y veremos como de sencillo es publicar y consumir un servicio REST, Asi que ya sabéis, si queréis hacer servicios webusad los mismos principios que hicieron la web posible, usad REST, hitpvfeamodorubio wordpress.com 2010107 26\servicics-web-2-4C2%BF que-es-rest! 2p