A lo largo de este tiempo, he tratado ya varias veces el tema de los servicios REST y su papel en una arquitectura orientada a servicios. Siempre he tenido la sensación de que este tipo de servicios, que tienen mucha ventajas, no encajaban bien en el escenario de SOA. En esta entrada, por ejemplo, hago hincapie que un servicio REST debería tener un descriptor del interfaz o contrato que proprciona a sus consumidores, de la misma forma que lo hace el fichero WSDL para los servicios SOA. Si bien es cierto, que el estándar WSDL 2.0 ya admite la descripción de servicios REST, y que tal vez sea el camino a seguir para solucionar esta carencia, lo cierto es que al día de hoy (y me temo que en mucho tiempo), la adopción de este estándar en las empresas es prácticamente nula.

En relación a este tema veo este artículo que trata precisamente lo que “le falta” a los servicios REST para ser considerados parte de SOA. Una reflexión muy concisa y clara sobre tres preguntas claves para entender la cuestión:

  1. ¿Dónde está la abstracción?
  2. ¿Dónde está el contrato?
  3. ¿Dónde esta la composición?

Abstracción

Según el autor del artículo, la visión que hace REST de las funcionalidades, donde todos son recursos, está demasiado limitada a la realidad de una lógica de negocio compleja. No tiene el suficiente nivel de abstracción que se necesita y creo que estamos bastante de acuerdo en esto.
Pongamos un caso sencillo. Se necesita implementar la funcionalidad de transferir dinero de una cuenta corriente a otra. Esta claro, intuitivamente, que una cuenta es un recurso y que el aumento o disminución de su fundo es una actualización de este recurso. Pero ¿podemos definir la lógica de sacar dinero de una cuenta para ingresarlo en la otra como un recurso? evidentemente podemos inventarnos el concepto “transferencia” pero creo que sería un poco forzado. REST está bien para definir los “nombres” : cuenta, cliente, tarjeta, etc. pero no tanto para los “verbos” (la lógica): transferir dinero, analizar riesgo cliente, etc. etc.


Photo credit: calgrin from morguefile.com

Contrato

Este tema ya lo he tratado en el blog como decía, no me extenderé más.

Composición

La teoría dice que si tenemos en la empresa cierto número de servicios ya desarrollados (una masa crítica de funcionalidades de negocio) dejaremos de “desarrollar” y nos dedicaremos a crear nuevas funcionalidades a base de “componer” o “ensamblar” servicios ya existentes. Esta es una de las grandes ventajas de SOA, y que no parece cubierta por una aproximación REST. Claro que llevando esto un poco al extremo se podría considerar que un servicio compuesto es un recurso de más alto nivel que está formado a su vez por otros recursos más sencillos. Sin duda, todo se puede implementar con REST, pero creo que llevando un poco al extremo su filosofía, metiéndola con calzador.

Conclusión:

Tenemos que examinar detenidamente el papel que van a tener los servicios REST en nuestro sistema. Tiene ventajas, como la simplicidad, pero también algunas carencias que debemos tener en cuenta.