Cami Can Calders, 8 2º-2ª | 08173 Sant Cugat del Valles info@bmotes.com 932504996

WhatsBee blog

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.

8 Comentarios

  1. Tin

    Hola,
    Boston, la ciudad es Boston.

    Muy bueno lo de los RESTafaris…

    Saludos,,

  2. kuropatula

    Carlos,
    Tengo una consulta genérica sobre los módulos. Estoy tratando de recibir por la UART del PIC. Realmente tengo experiencia en esto pero por alguna razón estoy trancado cuando recibo de los módulos Xbee.
    Lo que hago en el PIC es recibir en una interrupción y guardar en un array. Lo recibido lo muestro en un LCD y además lo guardo en la EE. Los datos que veo en el display y los que están en la EE coinciden, pero no son los correctos, ninguno de ellos, ni siquiera un byte.
    Estoy trabajando a 9600, 8N1, también probé bajar a 2400 y nada. Adapté los voltajes correctamente. Siempre recibo algo parecido, siempre empieza con 0x07, 0x61, 0x07 y luego otros bytes, pero creo que esto no es importante.
    Cabe aclarar que lo que muestro en el LCD, previamente lo paso a ASCII, es decir, si recibo 0x7E, muestro el ASCII del 7 y luego el ASCII del E. Sé que el error no está aca porque lo corroboro, como mencioné en los datos de la EE.
    Sólo te quería consultar si hay alguna sugerencia para esto.
    Saludos y gracias.
    Daniel

    1. Carlos (Publicaciones Autor)

      Kuropatula,

      lo que estás recibiendo son los paquetes en formato API, es correcto, el 0x07 es el start delimiter, es el byte que te indica que lo que viene a continuación es un API frame de Digi, los dos bytes siguientes son la longitud, etc.

      Entiendo que a ti lo que te interesa es el payload del paquete, si estás enviando ascii lo recibirás en ascii, por lo que deberás de quitar los encabezados. Lo entenderás mucho mejor si miras la página 99 del manual:

      http://ftp1.digi.com/support/documentation/90000976_G.pdf

      Saludos,

      Carlos

      1. kuropatula

        Hola Carlos, entiendo lo que me dijiste, pero no es este el caso. En realidad ya estoy bastante “empapado” (como leí que comentaste en otro post) con el modo API, reconozco las tramas bien, los frame types y demás. Sé perfectamente que tengo que recibir algo de la forma 7E 000F 91 01 ADDRESS y demás. Pero mi problema es que no recibo nada de eso. Todo lo que recibo en el X-CTU (que sé que es lo correcto) no es lo que recibo en el PIC. Mi duda era si estaba haciendo algo mal en el PIC (en lo que tengo experiencia, pero sé que es lo más probable) o hay algo más que estoy omitiendo en la comunicación X-Bee a PIC.
        El PDF que me pasaste ya lo había estudiado bien y más que nada en ese capítulo.
        Bien, espero haberme expresado bien esta vez,
        Saludos y gracias,
        Daniel

        1. kuropatula

          Lo que descubrí Carlos es que el PIC me da un Framing Error. Significa que los Start Bits y Stop Bits no son correctos. Aún no lo pude solucionar, cuando tenga la solución la comento.

          1. kuropatula

            Bueno, me funcionó. Con mucha vergüenza voy a comentar mi error. No está relacionado con ZigBee sino con PIC. El que utilizo, PIC16F886 lo configuré para 8MHz pero olvidé setear uno de los bits del registro OSCCON para que trabaje con 8MHz ya que por defecto trabaja con 4MHz.
            Lamento haberte molestado 🙁
            Saludos,
            Daniel

          2. Carlos (Publicaciones Autor)

            Daniel,

            no te preocupes por las molestias, me alegro de que lo hayas resuelto.

            Carlos

  3. Pingback: ThingSpeak: API RESTful para el Internet of Things open source | Zigbee labs

Dejar un comentario