Header Ads Widget

Ticker

6/recent/ticker-posts

Diseño de API para máquinas

 La cantidad de dispositivos conectados a Internet está creciendo a un ritmo asombroso. Según Cisco, en 2012, ¡había alrededor de 8,7 mil millones de dispositivos conectados! Solo en 2013, se conectaron más de 280 mil nuevos dispositivos cada hora, en promedio. Este año, ese número creció a más de 360 ​​mil nuevos dispositivos por hora. Cisco predice que dentro de seis años habrá más de 50 mil millones de dispositivos conectados en total, lo que hará que esta nueva malla sea la red más grande disponible hasta la fecha.

Gráfico de las proyecciones de Cisco para Internet de las cosas

Esta predicción crea interesantes desafíos de conectividad y, lo que es más importante, muchos desafíos relacionados con las API. Irakli Nadareishvili , quien presentó CA Technologies en el NordicAPIs Platform Summit , cree que “escribirás API de las que dependen millones de dispositivos . Si rompes tu API, millones de dispositivos lo harán ".

Si bien el software basado en la nube se actualiza fácilmente si hay un cambio de API, las cosas podrían ser diferentes en lo que respecta a los dispositivos. Para empezar, los dispositivos tienen una capacidad de procesamiento y almacenamiento mucho más limitada. Solo como ejemplo, Arduino Uno , que es uno de los dispositivos de bricolaje más populares disponibles, tiene solo 32 KB de memoria y funciona a solo 16 MHz. Esto significa que la mayoría de las instrucciones deberán estar codificadas en el hardware mismo, y hacer cambios será extremadamente difícil.

Otra cosa para recordar es que después de la implementación de los dispositivos, también será difícil realizar actualizaciones de software. La actualización de dispositivos de forma remota, sin duda, se volverá prohibitiva debido a los costos de ancho de banda. Además, realizar una actualización manual solo es posible si los dispositivos están al alcance de la mano, lo que no siempre es el caso.

Diseño de API duraderas

Se puede establecer una comparación interesante entre el desarrollo de software y la ingeniería civil. Mientras que la ingeniería civil se preocupa por la longevidad de las soluciones, el desarrollo de software se centra más en cómo la solución puede evolucionar y remodelar con el tiempo. Eric S. Raymond , un conocido defensor del código abierto y autor del libro La Catedral y el Bazar , popularizó el lema de “publicar temprano, publicar con frecuencia” que siguen millones de desarrolladores en la actualidad. Esta filosofía es perfecta para el desarrollo de software basado en la nube, pero resulta desastrosa en un entorno donde las máquinas serán los principales consumidores.

Según Roy Fielding , uno de los creadores de la especificación HTTP , la mayor parte del software se crea siguiendo el supuesto de que existe una única entidad que controla todo el sistema. En el caso de Internet de las cosas, todo el sistema está más distribuido y no existe una entidad única, central y controladora. Esto dificulta que los dispositivos consuman API que no se han creado para un mundo distribuido. Una posible solución es seguir nuestros pasos anteriores y utilizar una tecnología probada que nos permitió llegar a donde estamos hoy. Una parte de la arquitectura web que ofrece longevidad y funciona bien en un mundo distribuido es hipermedia.De hecho, “la Web como la conocemos no es más que millones de entidades hipermedia interactuando entre sí”, dice Nadareishvili.

Hypermedia ofrece una mayor longevidad que otras soluciones porque desacopla las implementaciones de servidor de la forma en que los clientes consumen API. Jakob Mattsson , de FishBrain, cree que "lo único que los clientes realmente necesitan es una comprensión genérica de hipermedia". No habrá necesidad de cambiar las implementaciones del cliente debido a cambios en el servidor, porque los clientes se adaptarán por sí mismos. Para que eso suceda, las respuestas de la API deben incluir datos y también controles que describan las prestaciones de la API. Luego, los clientes leerán esos controles y encontrarán su camino en la lista de posibles prestaciones. Los clientes, de hecho, se comportarán como lo hacemos los humanos cuando utilizamos un sitio web. Siempre que un sitio web cambia, no necesitamos leer ninguna documentación, simplemente navegamos y encontramos nuestro camino.

¿Hacer pensar a las máquinas?

El desafío con los hipermedia es que, mientras que los humanos somos muy buenos adaptándonos a los cambios y encontrando nuestro camino, las máquinas no lo son. Si bien el diseño de API para humanos debe consistir en comprender cómo los usuarios finales interactuarán con su API, el diseño de API para máquinas debe consistir en hacer que las respuestas sean fáciles de procesar. La clave de este desafío es encontrar familiaridad entre recursos similares. Al definir un conjunto de posibilidades similares para recursos similares, es posible crear un vocabulario que las máquinas puedan comprender. Esta ha sido la estrategia detrás del diseño de la interfaz de usuario durante décadas.

[bueno, xclass = ”text-center”] "Cada vez que me quedo atascado, pienso: ¿y si este fuera un sitio web?" - Irakli Nadareishvili, CA Technologies. [/ Well]

La principal diferencia entre los sitios web y las API, según Nadareishvili, es que "la mayoría de los sitios web son consumidos por personas reales que pueden comprender el significado semántico y aprender a realizar acciones en ellos". El hecho de que las máquinas no tengan la capacidad de interpretar el significado semántico de la forma en que lo hacen las personas se define como la brecha semántica . Una solución es utilizar técnicas de inteligencia artificial. Si las máquinas están habilitadas con la capacidad de comprender un vocabulario limitado, pueden derivar las acciones apropiadas de él.

RFC6906 describe una forma de lograr esto mediante la definición de perfiles que especifican cómo los servidores y los clientes comunican un conjunto de semánticas asociadas con los recursos. Un buen ejemplo de perfil es el podcast. Los podcasts tienen una lista muy específica de semántica y posibilidades asociadas. Si bien debería ser posible consumir un podcast con cualquier cliente, un cliente que conozca esta semántica puede proporcionar una experiencia más sofisticada. Existe un número creciente de estándares relacionados con el perfil para implementar la semántica requerida. Los siguientes son dos de los estándares que merecen especial atención:

  1. XMDP : el formato de perfiles de metadatos XHTML se utiliza para definir perfiles de metadatos HTML que son fáciles de leer tanto para humanos como para máquinas.
  2. ALPS : la especificación Semántica de perfil de nivel de aplicación es un formato de datos para definir descripciones simples de semántica de nivel de aplicación, similar en complejidad a los microformatos HTML .

Se trata de los estándares

Aunque ALPS se está convirtiendo en el estándar para los perfiles legibles por máquina, Nadareishvili dice que "hay muchas oportunidades de colaboración". La clave es utilizar el tipo de medio adecuado para que los clientes puedan adaptarse en consecuencia. Se espera que algunos clientes solo comprendan ciertos tipos de medios y simplemente descarten cualquier información de perfil que no comprendan. Idealmente, los clientes deberían analizar, y posiblemente almacenar en caché, toda la información sobre perfiles interesantes.

Cómo pueden hacer esto miles de millones de máquinas de baja potencia con conectividad limitada sigue siendo una pregunta abierta. Nadareishvili cree que "los dispositivos pueden utilizar MQTT e incluso comunicaciones de menor potencia". Los protocolos de conectividad como MQTT están diseñados para abstraerse de la capa de comunicación y son especialmente adecuados para conectividad limitada o intermitente. Otra opción es hacer un uso extensivo del almacenamiento en caché local e implementar protocolos de comunicación de una manera muy eficiente.

Otra solución obvia es aquella que permite a los proveedores de administración de API desempeñar un papel más importante. Los servicios de administración de API pueden proporcionar una capa intermedia y traducir las llamadas de API entre servidores y máquinas. Esto proporcionará puntos finales de API que las máquinas pueden consumir, además de una garantía de que nunca cambiarán. Estos servicios de traducción pueden entonces analizar los perfiles ellos mismos y hacer las adaptaciones necesarias para el consumidor. Cuando se le preguntó sobre esto, Nadareishvili expresó la creencia de que los proveedores de administración de API eventualmente ofrecerán dicho servicio tan pronto como el mercado lo demande.

Conclusión

Piezas de rompecabezas en la parte superior de una pantalla que muestra el código.

Existen grandes diferencias entre los clientes API basados ​​en la nube y los basados ​​en dispositivos. La antigua filosofía de "lanzamiento temprano, lanzamiento frecuente" que tiene tanto sentido en el mundo de las startups no es tan viable cuando se proporciona una API para el consumo masivo de miles de millones de dispositivos de baja potencia. Debido a que es tan difícil actualizar el código en los dispositivos implementados, las API no pueden cambiar. Esto hace que su mantenimiento sea un desafío interesante.

Una de las posibles soluciones es emplear tácticas relacionadas con los hipermedia al diseñar API, de modo que los clientes basados ​​en dispositivos puedan adaptarse fácilmente a cualquier cambio. Al definir los tipos y perfiles de medios adecuados, los proveedores de API pueden ofrecer al cliente pistas sobre las prestaciones que admiten y la mejor manera de consumirlas. Los clientes, por otro lado, deberán analizar y comprender esas sugerencias para adaptarse en consecuencia. El gran desafío en todo esto es que con una potencia de procesamiento y un ancho de banda limitados, ¿cómo obtendrán esa capacidad todos esos miles de millones de dispositivos?

¿Cómo crees que se puede resolver este desafío? ¡Deje un comentario aquí o envíenos un tweet con sus pensamientos!

Recursos

Aquí están los videos de la Cumbre de la Plataforma Nórdica de APIs de las charlas a las que se hace referencia en este artículo, por orden de aparición:

  • El desafío de Internet de las cosas: crear API que duren décadas ", Irakli Nadareishvili
  • Su API basada en HTTP no es RESTful ", Jakob Mattsson

Publicar un comentario

0 Comentarios