Restful

No es raro encontrarse en la empresa comentarios del tipo: “ahora que ya empezamos a servicios SOA, resulta que lo que piden son servicios REST”.

SOA y SOAP no son lo mismo

Bien, lo primero que hay que aclarar es que SOA no es sinónimo de servicios web, como se conocen a los WS-*. Ya sabemos que se puede hacer SOA sin SOAP y que se pueden tener cientos de servicios web y no ser realmente SOA (ver esta entrada).
Es verdad que, en la empresa, durante estos años la implementación más típica de SOA es la basada en esta tecnología. Sin embargo, en los últimos tiempos, con el auge de las aplicaciones web tipo SPA, con AJAX, y sobre todo, con las aplicaciones móviles, los servicios REST (que no son en absoluto nuevos), han proliferado por doquier. Hemos llegado al punto de que REST huele a moderno y SOAP antiguo. Como siempre no hay una cosa totalmente buena o mal, simplemente hay que usar cada tecnología en el sitio y en el momento más conveniente.

¿Hay volver a implementar los servicios SOAP como REST?

Después de sudar la gota gorda construyendo servicios SOAP ahora nos vienen con que necesitan servicios REST ¿hay que hacerlo todo otra vez?. Para responder a esta pregunta, yo lo analizaría desde dos puntos de vista:
  1. El estrictamente técnico (lenguajes, herramientas) con los que están construidos
  2. El diseño técnico de la lógica de negocio con los que está implementada la lógica de negocio que se provee en los servicios.
En primer lugar, si el lenguaje y la herramienta es lo suficientemente flexible y productiva, no debería costar mucho cambiar una implementación por otra. Al fin y al cabo en los dos casos se basan en transportan un “texto” mediante el protocolo HTTP. Es necesario por lo tanto disponer de servidores de aplicaciones en los dos casos y el perfil de los desarrolladores se parece bastante.
Sin embargo, nos queda un aspecto, el segundo al que me refería por diseño técnico.

Diferencias fundamentales entre SOAP y REST

Por otra parte, a nadie se le escapa que “orientación” de SOAP y REST es totalmente diferente. En el primero lo que se expone hacia el cliente son operaciones de negocio, como por ejemplo “presupuestar viaje”. El cliente nos manda una serie de datos (normalmente un documento XML), el servicio lo valida, ejecuta la lógica de negocio asociado y devuelve otro documento XML con la respuesta.
Sin embargo, en el caso de REST la cosa es bastante diferente. En primer lugar trabajamos con recursos o entidades de negocio, cada uno de estos recursos tiene un identificador (una URI) y sólo disponemos de 4 métodos de negocio (alta, baja, consulta y modificación).
¿Como traducimos el “presupuestar viaje” a REST? Los recursos se suelen asociar a nombres o entidades, así que el “viaje” está fácil. Seguramente en el diseño de nuestro sistema optaremos por tener un recurso viaje con la URI /miApp/viaje.
Podremos crear un viaje nuevo, borrarlo o cancelarlo, modificarlo y por supuesto consultarlo.
¿Pero que pasa con el verbo? ¿con la acción de “presupuestar viaje”? Está claro que no es un sustantivo y por lo tanto no se podría diseñar como un recurso, al menos no directamente… tendríamos que transformarlo a un nombre como “presupuesto”.
Así pues, nuestra operación de “presupuestar viaje” se quedaría en ejecutar las cuatro operaciones sobre la entidad
 
/miApp/viaje/presupuesto POST Crea un presupuesto
/miApp/viaje/presupuesto/{id} GET Consulta el prepuesto con identificador id
/miApp/viaje/presupuesto/{id} DELETE Borra o cancela un presupuesto
/miApp/viaje/presupuesto/{id} PUT Crea un prepuesto si ya conocemos a priori su identificador
Por supuesto, este es un caso sencillo. Si tenemos una aplicación con 30 o 40 entidades de negocio de este tipo, implementados con SOAP, pasarlo a REST no es en absoluto una tarea trivial.

¿Qué podemos hacer?

Creo que la mejor solución, y nada original, pasaría por hacer un primer diseño no ya orientado a SOAP ni a REST, sino orientado a objetos.
¿Que quiero decir con esto? que si hacemos un diseño a partir del dominio de negocio y de los requerimientos basado en clases (entidades) con sus atributos y operaciones o métodos sobre esas clases, será la base ideal para construir nuestros servicios independientemente de su implementación como servicio.
La parte importante, la lógica de negocio, estará estructurada mediante orientación a objetos. A partir de aquí, podremos añadir una “capa” de transformación de operaciones SOAP a objetos o de recursos y operaciones REST a estos mismos objetos. En el primer caso, podremos aplicar el patrón de diseño de fachada para “enlazar” la operación con los propios objetos. En el segundo caso, considerar una URI para cada uno de estos objetos y hacer que la “capa” sea capaz de traducir las 4 operaciones básicas de REST a las varios métodos que podremos tener.

Conclusión

En conclusión, mi consejo sería Orientación a objetos antes que SOA  y después, sobre estos, implementar SOAP y/o REST.
Anuncios