Arquitectura REST

Desafíos de una arquitectura REST

Introducción

En un artículo anterior explique desde mi punto de vista las diferencias entre SOAP y REST.

En esta ocasión vamos quiero explicar los desafíos que representa para el arquitecto de software la aplicación de este tipo de arquitectura.

Escenario

Asumiendo que lo que vamos a exponer son recursos con los cuales vamos a interactuar por medio de diferentes verbos, lo primero que tenemos que evitar es abrir nuestra capa de aplicación en métodos que ofrezcan la funcionalidad al mundo exterior. 

Supongamos el siguiente ejemplo:

Aquí tenemos un cliente HTTP que consume la capa de negocio de una aplicación por medio de una capa de servicio REST que trabaja con los verbos get, put, post, delete y search.

El resultado de esto es una aplicación cuya capa de presentación se encuentra desacoplada lo máximo posible del negocio. Así la capa de presentación puede ser diseñada, maquetada y programada por personas ajenas a cualquier tecnología propietaria de back end.

Desafíos 

Sin embargo tener una capa de servicios en formato REST no es necesario para lograr los mismos beneficios de esta arquitectura.

Esta capa podría implementarse perfectamente como WebService en formato SOAP o Json y mantendría los mismos beneficios.

La pregunta entonces es ¿ qué implicancias y desafíos tiene hacer una capa REST?

El principal cambio, desde mi punto de vista, es que lo que se expone con REST son recursos y el tipo de acción a aplicar sobre estos recursos son indicados por los verbos HTTP.

Si la capa de negocio tiene una buena arquitectura con patrones como Facade, la funcionalidad debería estar expuesta en forma de métodos que representan acciones de negocio. Y esto es muy distinto de lo que debemos hacer cuando pensamos en REST. Aquí los verbos están limitados a los estándares del protocolo HTTP (los más usados quizás son: get, put, delete, post, search) y lo que tenemos que pensar es QUÉ recurso vamos a exponer.

Por ejemplo, en una aplicación que maneja órdenes de compra y un usuario puede tener asignado para gestionar muchas órdenes de compra, es probable que todas las acciones que se puedan realizar sobre la orden sean métodos encapsulados de alguna forma por una o más fachadas (independientemente de la forma de despliegue).

Pero si queremos exponer esta fachada con una capa REST debemos pensar que el recurso en sí sería uno solo (la orden); la forma de leer las órdenes sería sobrecargas del verbo GET; las formas de buscar una orden serían sobrecargas del verbo SEARCH; y las respuestas a cada una de estas llamadas siempre debería ser un objeto de tipo orden (independientemente si se devuelve como Json o XML).

Si la orden tiene como atributo otro objeto más, como por ejemplo una sucursal, ésta debería ser en si misma otro recurso, y por lo tanto el cliente HTTP que quiera interactuar esta entidad tendría que usar los mismos verbos.

Consecuencias

Si continuamos con este análisis nos daremos cuenta que utilizar una capa de servicios REST implica centrarnos fuertemente en las entidades que vamos a compartir, porque esas entidades serían los recursos y lo que querramos hacer con ellas serán los verbos HTTP que vamos codificar y exponer.

Esto significa que si una entidad "Usuario" no tiene codificado una respuesta para el verbo SEARCH no se debería poder buscar esta entidad.

Otra aspecto que también sale a la luz es que claramente una capa de presentación cuya interacción con el back end sea por medio de servicios REST debe gestionar por si sola el renderizado y bindeo de todas estas entidades sueltas.

Por ejemplo, una sola página HTML puede que requiera disparar 4 llamadas GET, una para cada tipo de entidad que deba ser mostrada, ya sea en formato de combo, grillas o algún control combinado.

Conclusiones

A simple vista, generar una capa de servicios con WebServices parece mucho más simple y natural si es que estamos acostumbrados a la programación orientada a objetos.

REST se acerca más a la forma ideal con que fue concebida la web. Es una excelente forma de estandarizar la comunicación entre sistemas pero es posible que sea muy exigente para ser consumida directamente por una capa de presentación. 

Esta exigencia se debe a que la renderización e interacción de una página requiere utilizar múltiples llamadas con diferentes verbos.

Con REST es conceptualmente incompatible exponer como recurso ViewModels ya que por definición éstos son recortes del modelo especialmente creados para las vistas.

En síntesis, considero que utilizar REST implica un trabajo de análisis mayor por parte del arquitecto de software para no cometer errores o usos indebidos / forzados de esta maravillosa técnica.