Recientemente he asistido al evento Spring IO celebrado en Madrid el 17 y 18 de Febrero. Han sido un par de días bastante fructíferos por la calidad de sus charlas. La verdad es que me ha anotado varias cosas para experimentar y/o poner en práctica en mi trabajo (ya os iré contando).

Una de las que me llamó más la antención fue la charla a cargo de Sam Brannen titulada “Spring Web Services: REST vs. SOAP”. La verdad es que el “vs” sobraba del título porque en ningún momento realizó una comparativa de pros y contras entre los dos APIs. A no ser, claro está, lo que cada uno sacó al ver el mismo ejemplo programado de las dos maneras  (con SOAP y REST). Aunque por sencillez podría ganar esta última la verdad es que ambos parecían bastante sencillos de programar gracias al framework de Spring.

La primera conclusión que saqué fue que una vez más, Spring “pasa” de los APIs estándares de JEE como son JAX-WS y JAX-RS y crea su propio estándar de facto. Y como siempre, parece que lo ha hecho con éxito. A la acostumbrada calidad con la que hace esto logra también simplificar su uso (los APIs estándares suelen son más farragosos y complejos de utilizar).

Creo que los servicios REST son incluso más desconocidos que los servicios basados en SOAP (al menos en el ámbito empresarial). Sin embargo son más sencillos de usar, más ligeros en términos de rendimiento y si me apuran más fáciles de entender (aunque al principio por supueso cuesta un poco cambiar el chip si vienes de los web services SOAP).

Resumiendo, las características de REST son las siguientes:

  • Estos servicios interactuan con elementos de información a los que se llama recursos. Los nombres o identificadores de estos recursos (clave única) se representan con una URL. Por ejemplo http://www.miaplicación.com/identificadorVuelo/3442
  • Se basan en “verbos” que es lo que se puede hacer con los recursos. Para ello aprovecha los métodos del protocolo HTTP definiendo un CRUD de toda la vida
    • POST. Create o alta de un nuevo recurso
    • GET. Lectura de un recurso
    • DELETE. Borrado de un recurso
    • PUT. Actualización o UPDATE de un recurso
  • No tienen estado por lo que escalan muy bien
  • Los códigos de error son los del protocolo HTTP

Reflexionando sobre el uso de los servicios REST, la pregunta que me surge es… ¿como se posicionan estas dos formas de proporcionar servicios dentro de una arquitectura SOA? Empecemos por el principio:

En la arquitectura que tenemos en mi compañía, por poner un ejemplo, se han definido claramente tres capas de aplicación: el frontal, la capa de integración y la capa de lógica de negocio. Y digo claramente porque incluso cada capa se ejecuta en un servidor de aplicaciones diferente. En esta arquitectura, obviamente el frontal se dedica a la interacción con el usuario (el humano) presentando páginas web y recogiendo sus acciones que básicamente son realizar consultas y rellenar formularios para dar de alta información. La segunda capa, la de de integración o servicios, es la que expone los servicios de negocio (servicios web) que se ofrecen a toda la empresa siguiendo una arquitectura SOA. Los consumidores de estos servicios normalmente serían los frontales de las aplicaciones pero también pueden otros servicios más complejos, incluso otras aplicaciones de nuestros proveedores o clientes.

Lo primero que se podría pensar con los servicios REST es que son equivalentes a los servicios SOAP y por lo tanto deberían exponerse en la misma capa (en el ESB de la empresa). Esta es una opción muy válida y de hecho las herramientas de desarrollo de las mediaciones del ESB permiten ofrecer un servicio con este protocolo para ser consumido.

Sin embargo, al hilo de la charla del Spring IO como comentaba he empezado a cambiar de opinión. Por extraño que pueda parecer, en este momento me inclino más a considerar los servicios REST como parte de la capa de frontal en lugar de la capa de servicios ¿por qué?, veámoslo:

  • El tipo de cliente. Los servicios REST es el estándar de facto para todo tipo de APIs de los servicios de internet más populares del momento (Facebook, Twitter, etc. etc.) y se han popularizado aún más con la proliferación de las aplicaciones móviles en una vuelta al pasado de las aplicaciones cliente servidor realmente.
    Otro tipo de cliente muy numeroso serían las aplicaciones javascript que pintan las páginas dinámicamente basadas en AJAX. Aquí el cliente no es ni más ni menos que el propio navegador. De la misma manera que una aplicación de frontal normal en el que el navegador pide al servidor una nueva página que devuelve la presentación junto con los datos. Con los servicios REST, el servidor no devuelve la presentación, sólo los datos. En muchos casos, ni siquiera el servidor guarda el estado de la sesión, se guarda en el navegador.
  • El tipo de información. Como se ha visto en la conferencia de Spring REST, la información que se devuelve al cliente del servicio REST puede ser (de manera transparente para el programador) XML (lo normal) y también JSON. Es decir, se devuelve una notación javascript que será interpretada por la librería javascript que se está ejecutando en el navegador del usaurio. Si se devuelve javascript, ¿puede considerarse un servicio de negocio?
  • Acoplamiento con la presentación. Una de las características clave de los servicios de negocio según SOA es que estos tienen sentido para el negocio. Es decir, proporcionan funcionalidad Core de negocio del tipo “reservarVuelo” o “solicitarHipoteca”. El uso de los servicios REST en la mayor parte de los casos está muy acoplado a la presentación, es decir, resuelven el problema de proporcionar información para ser consumida en una pantalla. Por lo tanto, aunque esta característica no es intrínseca de este tipo de servicios, es más bien un uso común que se le ha dado, se pierde el sentido de servicio de negocio.

Conclusión:

  • Los servicios REST pueden considerarse como parte del frontal o servidor de presentación dentro de una arquitectura SOA
  • El uso de un framework como Spring REST simplifica el desarrollo con un modelo orientando a objetos (POJO) y hace transparente el formato elegido del mensaje (XML, JSON, etc.)

Comparte esta entrada:

Share