Rest

REST

REST (Representational State Transfer) [1] es un estilo de arquitectura presenta por Roy Fielding  en su disertación doctoral el año 2000. Es un enfoque  en el que los clientes usan URL y las operaciones HTTP GET, PUT, DELETE y POST para manipular recursos que están representados en XML. El énfasis está en la manipulación de los recursos de datos más que en las interfaces. Cuando se crea un nuevo recurso, tiene una nueva URL mediante la cual se puede acceder o actualizar. A los clientes se les proporciona el estado completo de un recurso en lugar de llamar a una operación para obtener una parte de él.

Rest se basa en los  principios descritos a continuación:

• Interfaz uniforme. Para lograr una interfaz REST uniforme se requiere que la Identificación de recursos, manipulación de recursos a través de representaciones (los recursos deben tener representaciones uniformes en la respuesta del servidor), Mensajes autodescriptivos (cada representación de recursos tiener suficiente información para describir cómo procesar el mensaje) e  Hipermedia como motor del estado de la aplicación (el cliente debe tener solo el URI inicial de la aplicación). 
• Cliente-Servidor. El patrón de diseño cliente-servidor impone la separación de intereses, lo que ayuda a que los componentes del cliente y del servidor evolucionen de forma independiente. 
• Sin Estado:  exige que cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender y completar la solicitud. 
• Cacheable  o almacenable en caché: requiere que una respuesta se etiquete implícita o explícitamente como cacheable o no cacheable.
• Sistema en capas: permite que una arquitectura se componga de capas jerárquicas al restringir el comportamiento de los componentes.
• Código bajo demanda. REST permite que la funcionalidad del cliente se extienda mediante la descarga y ejecución de código en forma de applets o scripts.

Aplicación de comercio electrónico.

A continuación y como ejemplo práctico de desarrollo un aplicaciones de microservicios usando Rest,  se presenta el desarrollo de una aplicación de comercio electrónico usando una arquitectura orientada a microservicios (tomada de [1]). La metodología de  desarrollo que se muestra se basa en la metodología propuesta  por [2,3] para la implementación de microservicios.  A continuacion, los aspectos resaltantes del diseño de la aplicación.

1. Diseño del Monolito.  

Identificar qué entidades pertenecen al dominio de la aplicación, y qué interacciones y relaciones habrá entre las mismas, lo cual es posible de evidenciar mediante el diseño de un diagrama entidad y relación.

Diagrama entidad relación de una aplicación de comercio electrónico. Tomada de [1]

2. Casos de Usos.

Se diseña los casos de usos, entre ellos,  el proceso de compra de producto y el proceso de administración. En el primero, figura izquierda, se proyectan  dos procesos: compra manual y compra automática. En la compra manual el usuario obtiene la información del vendedor para que determinen el método de pago mientras que en la compra automática el pago se realiza cuando el usuario decida a través de la plataforma de servicio externa.

Caso de Uso Compras. Tomado [1]

Caso de Uso Administración. Tomado[1]

En el caso de uso de la figura derecha, se pueden ver las acciones que puede hacer un usuario cuando entra al módulo de administración, en la cual puede gestionar distintos procesos acerca de sus compras, ventas, productos, reputación y configuración de su cuenta. 

3. Diseño del API 

Se  especifica  la definición de la interfaz de la API Rest que expone la aplicación monolítica, ya que esta sirve como guía para detallar que recursos manejan los servicios y como se ofrecen. Los servicios de una API, son un contrato entre el servicio y sus clientes, es importante definir precisamente los servicios de la API usando algún tipo de lenguaje de definición de interfaz.  Se usa un lenguaje de definición de interfaz , por ejemplo  ApiBlueprint, que engloba el conjunto de suposiciones semánticas sobre la sintaxis usada para describir la interfaz de la aplicación. 

4. Diseño de  Microservicios

Se proyectan  los microservicios, y como primer paso se define  el contexto límite (bounded context) de la aplicación.  para delimitar los dominios de la aplicación.  

Contexto limites  aplicación Comercio Elctrónico. Tomado de [1]

Los contextos límite son Producto, Publicación, Orden y Usuario. El contexto límite Producto es responsable de gestionar los productos y sus ofertas. Publicación gestiona la información de las publicaciones asociadas a los productos del comercio electrónico y sus comentarios. El contexto Orden gestiona el proceso de órdenes de compra. El contexto  de Usuario gestiona la información de los usuarios que se registran en la aplicación de comercio electrónico.

 Se diseña cada microservicio a partir de los contextos limites descritos arriba. En la figura siguiente se muestra los  cuatros contexto límite definido. Cada uno de ellos se proyecta como un microservicio, pero también es posible que cada entidad sea un microservicio; por ejemplo, en el contexto Producto, pudiera generarse el microservicio de Producto y el microservicio de Oferta, sin embargo, si la comunicación entre ambos microservicios es muy frecuente, debe considerarse la latencia del sistema distribuido asociada con la comunicación entre ambos microservicios. 

Entidades agrupadas según contexto limite. Tomada de [1]

En la siguiente figura  se presenta un esquema de la aplicación comercio electrónico utilizando los microservicios definidos a través del contexto límite:    

 

Aplicación Comercio Electrónico. Tomado de [1]

 Un aspecto importante para resaltar, es que en el microservicio de Orden se usa un adaptador de un proveedor externo, conocido este término como third-party API, esto con el fin de gestionar los pagos a través de una Api de un servicio externo. 

5. Escoger patrón comunicación Cliente-Microservicio 

El patrón de comunicación Cliente-Microservicio escogido en la aplicación fue el API Gateway, dado que este patrón evita que los clientes tengan una  comunicación directa con cada microservicio para pedir una información específica. El API Gateway es la puerta de entrada a la aplicación, que le permite al cliente tener comunicación con los microservicios. Aunque por sí mismo, no es considerado como un microservicio, este sigue siendo una parte del sistema, y por ende, debe ser diseñado, desarrollado y desplegado.

El API Gateway diseñado usa la interfaz REST ya definida en la sección 3, por lo que las peticiones hechas hacia las API deben ser por el protocolo HTTP. Dentro de la aplicación el API Gateway cumplirá con la función de ser el principal orquestador de los microservicios, y se encargará de agregar y agrupar las respuestas que devuelvan estos, para así devolver una única respuesta al cliente que realice la petición.

La comunicación entre el cliente y el API Gateway será a través de HTTP, pero la comunicación entre el API Gateway y los microservicios será por RPC, como se muestra la figura. Se observa  como el cliente web (navegador) realiza una petición HTTP con el método POST al endpoint /api/user/account con el fin de crear una nueva cuenta de usuario dentro de la aplicación, posteriormente el API Gateway se comunica con el microservicio de usuario a través de RPC y como paso final devuelve una respuesta al cliente para indicar que la creación de su cuenta de usuario fue exitosa.

Protocolo de comunicaciones. Tomado de [1]

   

La arquitectura completa de la aplicación se muestra en este esquema:

Arquitectura de aplicación Comercio Electrónico. Tomado de [1]

 6. Descubrimiento de Servicios

Cada microservicio posee un registro local,  pero es necesario un mecanismo de eventos a través del cual un microservicio pueda comunicarle a los demás que se encuentra disponible o que ha dejado de estarlo. Para esta tarea se utilizó RedisDB, que es una  base de datos en memoria que puede funcionar como una caché o agente de mensajes (publicador/suscriptor).  

 El proceso que siguen los microservicios de la aplicación al momento de guardar y borrar información de sus registros locales es el siguiente:

• Se despliega un microservicio en su entorno correspondiente. A su vez, este microservicio se suscribe a un canal compartido de RedisDB que le permitirá recibir mensajes publicados por otros microservicios. Figura izquierda.
• Al ser desplegado, el microservicio publica un nuevo mensaje en el canal compartido, en el cual envía información que contendrá su IP, puerto e ID.  Figura derecha.

• Los microservicios que se encontraban previamente disponibles, reciben el nuevo mensaje publicado por el microservicio que acaba de desplegarse, y proceden a guardar en su registro local la información de este. Figura izquierda.
• Estos microservicios también envían su información a través del canal compartido, para que el microservicio que acaba de ser desplegado guarde en su registro local toda la información de los otros microservicios que ya se encontraban disponibles. Figura derecha.

• Cuando algún microservicio se detiene por alguna razón, este envía un mensaje por el canal, indicando a los demás microservicios que deben borrar su información de su registro local:

Una vez registrados los microservicios es necesario descubrir su ubicación para entablar una comunicación entre estos a través de RPC. El proceso para descubrir a otro microservicio dentro de la aplicación es el siguiente: 

1. Un servicio (API Gateway o microservicio) busca dentro de su registro local, en que puerto y en que IP un microservicio específico se encuentra disponible. 
2. Una vez que se ha obtenido la ubicación del microservicio, se realiza la comunicación con éste a través de RPC

Descubrimiento de Servicios. Tomado de [1].

7. Orquestación

Dentro de la aplicación, el API Gateway se encarga de enrutar cada petición al microservicio que corresponda, por lo que, el API Gateway es el cerebro orquestador de la aplicación. Un caso de orquestación se muestra cuando se intenta consultar el detalle de una publicación, debido a que,  es necesario consultar a varios microservicios para devolver una respuesta al cliente.

En la figura siguiente se observa como el API Gateway se comunica con el microservicio de Publicación para obtener los detalles de la publicación que se desea consultar; una vez obtenida esta respuesta, se comunica con el microservicio de Producto para obtener el detalle del producto que está asociado con la publicación consultada; y en última instancia, pasa a comunicarse con el microservicio de Usuario para obtener la información del usuario (vendedor) al que le pertenece dicha publicación. En todo este proceso el API Gateway se encarga de ir consultando uno a uno los microservicios e ir agregando la información devuelta por cada uno de estos, para luego dar una respuesta unificada al cliente. 

Diagrama de secuencia Detalle Publicación. Tomado [1].

8. Coreografía

En la figura  se presenta el proceso de creación de una publicación. En dicho proceso se puede observar que cuando el API Gateway envía una petición al microservicio de Publicación para crear una nueva, este último actúa en consecuencia invocando al método checkOnwerShip del microservicio de Producto, para saber, si el producto que se desea asociar a la nueva publicación, le pertenece al usuario que realizó la petición inicial. Esta acción en consecuencia llevada a cabo por parte del microservicio Publicación, es característico de un enfoque coreógrafo. Para este caso la interacción de la comunicación sigue siendo síncrona, ya que, para cada petición realizada, se espera una respuesta para poder continuar con el proceso.

Diagrama de colaboración: Creación de publicación. Tomado de [1]

 

Referencias

1. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.
2. Newman, S. Building Microservices. O'Reilly Media, Feb. 2015. 
3. Richardson, C., and Smith, F. Microservices from Design to Deployment. NGINX, Inc. 2016. 
4.  Thomas Erl, Service Oriented Architecture: Principles of Service Design. The Prentice Hall Service-Oriented Computing Series by Thomas Erl. 2007