Sobre REST como alternativa válida a SOAP para la invocación de servicios mediante HTTP

Hoy he estado leyendo información sobre REST (REpresentational State Transfer http://es.wikipedia.org/wiki/Representational_State_Transfer ) en su relación más directa con la invocación de servicios por el protocolo HTTP. Básicamente, se trata de la invocación de servicios simplemente a través de una invocación a una URL conocida enviándole los parámetros que se precisen.

En este post me gustaría exponer las conclusiones a las que he llegado en mi “muy-por-encima” aproximación a este nuevo estándar.

Exposición de funcionalidades a través de REST

Los servicios expuestos a través de REST no precisan de un descriptor como podría ser un WSDL para el caso de los Web Services. Esto es debido a que, desde su diseño, contemplan los siguientes principios básicos:

• Todos los “ítems” expuestos deber estar identificados, tener un ID único que los diferencie del resto. Un ID perfectamente válido podría ser una URI para cada uno de los “ítems de negocio” sobre los que se pueden invocar servicios. Ejemplos de esto podrían ser: peticiones, productos, clientes, etc.


• En el caso de “ítems” compuestos, los elementos componentes deberían a su vez ser presentados por su identificativos – URI (algo, según mi parecer, nefasto desde el punto de vista del rendimiento para la mayoría de los casos, porque imposibilita recoger toda la información necesaria en una única llamada para ciertos escenarios). Un ejemplo para este caso podría ser el siguiente:
  



• Hablando ya del mundo de la Orientación a Objetos, y relacionando los ítems como objetos, los métodos a implementar dentro de los mismos deberán ser estándares y corresponderse con los “verbs” del protocolo HTTP: GET, PUT, POST y DELETE. Esto se debe principalmente a la carencia de descriptores claros de las funcionalidades que se pueden llevar a cabo. Esto no obliga a implementarse estas funcionalidades para todos los objetos. Esto puede obligar, desde el diseño, a pensar sobre esta filosofía ya que esta restricción puede obligarnos a la creación de un mayor número de ítems/objetos de los que sería estrictamente necesarios en la programación OO. Este problema desaparecería con la utilización de Web Services con varios métodos que podrían actuar sobre uno o varios objetos.

• La comunicación con estos servicios debe ser sin estado. Stateless. Esta característica busca promover la escalabilidad de los sistemas. Un debate parecido podría surgir dentro del universo J2EE en la utilización de los dos tipos diferentes de Session EJBs: sin estado (stateless) o con estado (stateful).
  Para que esto sea posible, en el diseño de los servicios éstos han de definirse como “idempotentes” y, en muchos casos, esto no es trivial. Incluso me atrevería a decir que imposible.La carencia de estado conversacional, hace que, en aquellos casos en los que sea necesario, éste deberá ser gestionado en el cliente.

Recomendación

Creo que REST, en su vertiente más pura, es una alternativa válida para la invocación de servicios que no tienen especiales requerimientos de seguridad, transaccionalidad, etcétera. Alguno de estos ejemplos podrían ser la interacción con sindicadores de contenido RSS o el acceso y publicación de contenidos en un Blog. No obstante, hay algunas empresas referentes en lo que ha venido a denominarse como la Web 2.0. Son los casos de Amazon (http://www.amazon.com/AWS-home-page-Money/b?ie=UTF8&node=3435361 ), eBay (http://developer.ebay.com/developercenter/rest/ ) y Yahoo (http://developer.yahoo.com/ ).

Además, los principales frameworks de Web Services de Java, como es el caso de Axis 2, ya se declaran “REST compliant”. De hecho, aquellos que lo cumplen lo marcan como un elemento diferenciador del resto. Esto puede hacer pensar que, posiblemente, REST deje pronto de ser una tecnología marginal en cuanto al uso para pasar a ser una alternativa más seria al hoy por hoy todopoderoso SOAP.

No obstante, la posibilidad de exposición de funcionalidades por REST no hay que perderla de vista. Tiene ciertas ventajas que residen básicamente en la simplicidad de su uso. Por el contrario, existen ciertos aspectos ya resueltos por los diferentes estándares de los Web Services que son necesarios para multitud de escenarios de negocio. Para los casos en los que la interoperabilidad y los requerimientos transaccionales o de seguridad (amén del resto ya cubierto por los diferentes estándares WS*) no sean triviales, creo que SOAP hoy en día tiene la madurez y el apoyo de la industria necesario para ser la principal alternativa para la exposición de servicios.