RESTful: La mejor solución para el brokerage de datos

Dicen en mi tierra que el que sabe de todo no es especialista en nada, me siento claramente identificado con esta frase. Por otro lado y en mi defensa citaré una frase de Danny Kaye «Un especialista es una persona que cada vez sabe más sobre menos, hasta que termina sabiéndolo todo sobre nada… y nada sobre todo».

Hace unos días estuve en el Bdigital global congress organizado por Bdigital en Barcelona, los dos primeros días el tema central de las ponencias fué sobre los Smart Cities Projects. Entre muchas ponencias en las que se habló de la implantación de proyectos poco novedosos (desde mi punto de vista) y en la que algunos fabricantes/integradores venían a «vender» su proyecto hubo una ponencia de Esteve Almirall. Esteve Almirall tiene la gran virtud de elevar un poco el nivel en este tipo de actos, no se limitó a describir un la implementación de un proyecto o las virtudes de un producto, sino a explicar y a desarrollar una buena sobre idea open governement data apoyado en un «business case», sobre los datos de la frecuencia del transporte público en una ciudad de EEUU (disculpadme, pero no me acuerdo de cual).

La tesis defendida por el Sr. Almirall era que los datos generados por un gobierno deberían de ponerse a disposición de los ciudadanos mediante estándares abiertos y API’s públicas. Los datos de utilidad serán utilizados por los propios ciudadanos que crearán interfaces y probablemente los harán públicos para otros ciudadanos, bien como un servicio gratuito a la comunidad o como parte de un servicio de pago. De una forma muy sencilla, la idea, es que en una administración pública es mucho más eficiente dedicar los recursos a poner la información en un formato abierto en manos de los ciudadanos que dedicarlos a crear una app para el iphone. Si los datos son de utilidad, y se publican en un formato abierto, es probable que la aplicación la cree una tercera persona, de hecho es muy probable que aparezcan muchas aplicaciones en muchos entornos diferentes que se aprovechen de la información y que contribuyan a difundirla, que al fin y al cabo es de lo que es trata.

Después de la ponencia vi clara la aplicación en nuestro proyecto, trabajando en una capa de abstracción de los datos de los sensores, haciéndolos públicos, cualquier consumidor de los mismos podrá crear aplicaciones y, posiblemente, ponerlas al servicio de la comunidad. Básicamente lo que hace Pachube.

Cuando me decidí a sacar los datos de la red Zigbee hice una primera prueba con XML-RPC, es de fácil implementación, pero ha sido reemplazado por el SOAP, hice un pequeño desarrollo sobre Visual Basic 6 con un control ActiveX libre que me descargué, la verdad es que funcionó, pero no me quité de encima la sensación de ser una tecnología obsoleta, ¿cómo te puedes poner a desarrollar sobre tecnologías obsoletas y quedarte tan tranquilo?

RESTafari

Mi segundo intento fué utilizando SOAP sobre VB.NET. Me dió la sensación de ser una tecnología muy sólida y muy sencilla de implementar entre dos aplicaciones programadas en VB.NET. Analizando las respuestas de SOAP me dí cuenta de que son muy completas, pero demasiado complicadas. La complicación no es un problema para un equipo publicando servicios web y otro consumiéndolos, de hecho es bastante transparente. El problema es que, con mucha frecuencia, en el tema que nos ocupa hay un equipo con una gran capacidad de cálculo (el que publica los servicios) y otro con muy poca capacidad de cálculo y muy poco espacio en memoria. Que la respuesta que reciba el consumidor de los servicios web sea muy compleja (incluyendo por ejemplo información de tipos) es un problema a la hora de parsearla en un equipo con poca capacidad (en un mote por ejemplo).

Mirando diversas API’s conocidas pude observar que las respuestas no eran tan complejas como las que proporcionaba el SOAP, por lo que concluí que tenía que haber una tecnología de una complejidad «intermedia» entre el XML-RPC y el SOAP. La tecnología es REST. Según la definición de Wikipedia:

La Transferencia de Estado Representacional (Representational State Transfer) o REST es una técnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

Si bien el término REST se refería originalmente a un conjunto de principios de arquitectura —descritos más abajo—, en la actualidad se usa en el sentido más amplio para describir cualquier interfaz web simple que utiliza XML y HTTP, sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de mensajes como el protocolo de servicios web SOAP. Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y también es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas, aunque RPC no es un ejemplo de REST.

Y, como premio para el que haya llegado hasta aquí, explicaré el misterio de la foto del artículo:

Los sistemas que siguen los principios REST se llaman con frecuencia RESTful; los defensores más acérrimos de REST se llaman a sí mismos RESTafaris.