Recurriendo a los recursos para construir soluciones

Cuenta la leyenda que una vez la humanidad intentó colaborar para construir una torre que llegara al cielo. De igual modo los sistemas y aplicaciones se comunican y colaboran desde algún tiempo a través de distintos mecanismos para construir soluciones cada vez más elaboradas y poderosas.

Numerosas tecnologías han desfilado como soluciones a este planteamiento, desde llamadas a procedimiento remoto (RCP), CORBA, Java con RMI y más tarde con los Session Beans hasta protocolos como SOAP y servicios web que transportan información via HTTP.

La tendencia parece ser simplificar cada vez más los formatos de intercambio y exponer la información por medio de protocolos ligeros y estándar para facilitar la transmisión de datos a través de una red, así como el procesamiento de los datos una vez que llegan al dispositivo solicitante.

Hoy en día se escucha mucho de REST y la construcción de interfaces que permiten exponer datos y disparar acciones a manera de servicios desde aplicaciones de terceros.

Algunos casos de uso de un REST API son:

• Integración de sistemas.
• Automatización de tareas.
• Backend para aplicaciones móviles
• Generación de aplicaciones reactivas (Que amerita su propia entrada de blog inspirada por Freya)

En el siguiente vínculo hay una descripción ámplia, precisa y hasta matemática de los conceptos que tienen que ver con REST.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

De igual modo se intentará sintetizar el conocimiento surgido de quebrarse la cabeza (otros objetos alrederor y por poco algunos cráneos) al implementar soluciones y así resaltar algunos puntos relevantes de la forma más pragmática posible.

Entre recursos y otras artes oscuras

Recurso es el concepto clave en REST, el cual es una abstracción de información identificada por un nombre. Ej: Un documento o imágen, una colección de otros recursos, una persona, un servicio, etc.

Los recursos REST son accesibles a través del protocolo HTTP a través de URL's, usando un método específico, como GET , POST , PATCH , PUT y DELETE . Cada método es una solicitud para realizar una operación en el recurso.

• GET. Recupera un recurso 
• POST. Genera un nuevo recurso a partir de los parámetros de la petición
• PATCH. Realiza una actualización parcial en el recurso
• PUT. Realiza una actualización total en el recurso
• DELETE. Elimina el recurso

Algunos ejemplos de rutas estilo REST son:

Verbo HTTP	Ruta	Descripción
GET	/orders	Muestra una lista de órdenes
GET	/orders/:id	Muestra una órden específica
POST	/orders	Crea una nueva órden
PUT/PATCH	/orders/:id	Actualiza una órden específica
DELETE	/orders/:id	Elimina una órden específica
GET	/orders/cancelled	Recupera una lista de órdenes canceladas
GET	/orders/:id/items	Recupera los artículos de una órden específica
PATCH	/orders/:id/send/	Actualiza el estado de una órden específica e inicia el envío

Cabe señanar que el pensar "a la REST", permite organizar la estructura de una aplicación, ya sea un REST API o una aplicación web tradicional,  basándose en una convención dictada por la industria. Esto ayuda a evitar que los desarrolladores o arquitectos "creativos" definan estructuras que pueden llegar a ser muy complejas y difíciles de manterner.

Las 3D's del génesis

Los recursos que son accedidos o modificados son básicamente un conjunto de conceptos relativos a un problema de negocio específico. Cada concepto puede visualizarse como una entidad la cual está descrita por una serie de propiedades y relaciones con otras entidades lo cual para "la bandota" se conoce como modelo del dominio.

Este modelo del dominio nos remite a una práctica dentro de la ingeniería de software llamada diseño dirigido por dominio (domain driven design o DDD), la cual sostiene que el desarrollo de una solución debe estar basada en un modelo generado a partir de conceptos del negocio particular que se quiere abordar así como encapsular la lógica y reglas que dicte el mismo negocio.

Una vez que se tiene un modelo de dominio robusto y probado (donde entra en juego el desarrollo dirgido por pruebas o TDD), solo resta exponer ese dominio como recursos con la acción que aplique para cada caso.

Este modelo del dominio también funciona como un formato homologado de información entre aplicaciones y plataformas, pues independientemente de la tecnología propia de cada solución, las estructuras de datos dictadas por el modelo de dominio pueden ser implementadas puntualmente por cada tecnología, ejemplo.

• Modelos active record para un backend Ruby on Rails
• Clases Java para una aplicación Android
• Clases Swift u Objective C para una aplicación IOs
• Objetos JSON para intercambio de inforrmación sobre HTTP.
• Objetos JSON para una aplicación basada en Angular o JQuery
• Tablas y llaves foráneas para una base de datos relacional
• Documentos JSON para una base de datos MongoDB o DynamoDB

Anarquía de una tierra sin estado

El protocolo HTTP es por definición sin estado, esto es que una petición guarda un registro de otras peticiones. Esto se extrapola a los servicios ofrecidos por un API REST donde una petición específica no tiene acceso a los datos de peticiones anteriores. 

Una gran ventaja de tener servicios sin estado es la facilidad de crecimiento horizontal que se tiene. Dado la naturaleza sin estado de los servicios es posible generar replicas del servicio y solo utilizar un balanceo de carga para incrementar la capacidad de atención de peticiones.

En un ambiente de nube se puede utilizar el concepto de elasticidad para incrementar o decrementar las réplicas del servicio sin necesidad de mecanismos como la replicación de sesiones.  En el caso de Amazon servicios como Elastic Load Balancer, EC2 y Autoscaling permiten hacer esta magia de forma relativamente sencilla con la opción de agregar otras "monerías" como monitoreo, certificados digitales, replicación en otras regiones, etc.

El Can Cerbero Tokenizado

La seguridad es un tema obligado en cualquier solución tecnológica con el fin de garantizar tanto como sea posible la integridad, confidencialidad y disponibilidad de la información.

El uso de tokens es el mecanismo recurrido para implementar ciertas medidas de seguridad. Para esto pueden distinguirse dos tipos de tokens.

• API Token. El proveedor de servicios genera un token único por aplicación que pretende utilizar los servicios expuestos a manera de REST API. Dicho token es solicitado y utilizado para verificar la aplicación cliente. Los API's de Facebook, AWS o Google son ejemplos que utilizan este mecanismo. Una forma de implementar esto es a través de un API Gateway el cual puede ser utilizado para agregar medidas adicionales como prevención de ataques de DoS.
• Access Token o Auth Token. Utilizado para identificar y autenticar una cuenta de usuario de la aplicación. Dado que este mecanismo permite asociar las llamadas a un cliente en particular se vuelve una manera de implementar una sesión de usuario donde el estado conversacional se mantiene en el cliente. 

Dentro de las ventajas del uso de tokens pueden mencionarse:

• Los tokens pueden ser forzados a expirar como modo de revocar el acceso a un usuario o aplicación.
• Los tokens son cadenas alfanuméricas únicas generadas por el REST API, lo que robustece la aplicación ante ataques de diccionario, fuerza bruta o ingeniería social.

Cabe mencionar que los REST API suelen ser expuestos mediante HTTP SSL/TSL y los tokens suelen enviarse como cabeceras de cada petición para evitar el secuestro de sesiones o la alteración de la información que viaja hasta el proveedor de servicios.

Cache-ando ando

Mucha información consultada tiene muy pocos cambios a lo largo del tiempo, por lo que almacenarla en un cache local incrementa el rendimiento de las aplicaciones cliente al reducir la cantidad de llamadas remotas al proveedor de servicios.

Se pueden identificar dos niveles de cache

• Memoria. Mantiene una copia en memoria de los datos recuperados desde la fuente. Se recomienda para cantidades moderadas de datos que son consultados frecuentemente. Ej, catálogos estáticos, información de la cuenta de usuario.
• Archivos. Genera archivos locales a partir de la información recuperada desde la fuente. Empleado para archivos binarios como imágenes y documentos o grandes cantidades de texto.

Cuando se tiene identificada información que cambia periodicamente puede configurarse el cache para que información específica expire obligando a que sea actualizada desde el origen.

De igual modo es posible manejar diversos caches en diferentes puntos de toda una solución. Si bien se hablaba de un cache local en un cliente (dispositivos móviles o un navegador web), también es posible habilitar bases de datos en memoria (Redis, Memcache, Coherence) donde los REST API puedan almacenar información obtenida de otros repositorios (bases de datos, documentos, etc) y así mejorar los tiempos de respuesta.

La asincronización hace la fuerza

Dado que un REST API expone una serie de servicios remotos, es preferible (y en algunos casos mandatorio) acceder al API de manera asíncrona. De este modo la aplicación cliente puede continuar con su labor o incluso consumir diferentes servicios de manera cuasi simultánea. Por ejemplo mientras se está descargando una foto del portal de Suicide Girls, la aplicación puede estar generando una gráfica, recibiendo una notificación y enviando información de uso.

Aunque tanta magia simultánea requiere un cambio de paradigma en como se desarrollan las aplicaciones cliente, pues ahora el modelo de programación es basado en eventos y notificaciones de cuando una tarea asíncrona es concluida.  

El acceso asíncrono, junto con los esquemas para mejorar la disponibilidad y el poder de cómputo distribuido potencial de las aplicaciones cliente (móviles, web browser, etc) pareciera que nos ván remitiendo a terrenos del manifiesto reactivo. Esto me sugiere que un REST API puede ser un componente de solución para implementar una ansiada arquitectura reactiva (alguna vez Gus me dijo que quería construir una aplicación de este tipo). Pero eso será tema de otra entrada de blog y otro sueño de una noche de insomnio y valkirias.