¿Cómo de privada debe ser mi API?

Tal y como entiendo, los datos públicos (opendata) deberían ser expuestos mediante APIs públicas de forma que estén disponibles para los ciudadanos, y todo aquel que quiera utilizarlos.

En el caso de las empresas, dependerá de su modelo de negocio, de hecho exponer servicios con acceso directo a los objetos de negocio debería hacerse en distintos niveles, que tal y como yo veo podrían ser los siguientes:

  • Por ejemplo, en un cierto nivel sólo aquella información que quiera suministrarse de forma pública, API pública, estaría disponible para la comunidad global de forma que pueda se expanda el conocimiento de productos y servicios de la compañía, u otras informaciones que la compañía deba exponer por algún marco regulatorio. Este API sería de acceso público con libre acceso y registro a la comunidad, o con acceso restringido a una gran comunidad de clientes.
  • Avanzando en cuanto a privacidad, habrá otros modelos del datos de la compañía que estarán restringidos para intercambio con otras empresas (lo que se denomina business to business – b2b ). De esta forma las aplicaciones de terceros que consuman las APIs privadas formarán parte de una o más comunidades privadas a las que deberíamos ofrecer distintas APIs dependiendo del escenario, por ejemplo intercambio de información de pagos y cobros, de pedidos y facturas, movimientos de almacén, etc. Estas son las comúnmente llamadas APIs privadas.
  • Y en el último nivel de restricción, habrá APIs de uso interno, lo cual no quiere decir que sean APIs que se puedan consumir internamente a discreción, si no que su existencia implica también un gobierno sobre su ciclo de vida, notificación a los consumidores de nuevas versiones o cambios, y control del consumo del API y de las condiciones del servicio por parte de los distintos consumidores. Estos consumidores internos pueden perfectamente ser otros sistemas, lo que tradicionalmente se llama integración application to application – A2A. Yo llamo a estas APIs internas, aunque muchas veces son APIs propietarias de los componentes software que la compañía utilice, SCM, CRP, CRM, HR, ERP.

Esta gestión de los diferentes niveles de privacidad de la información, y por tanto de las diferentes APIs que se utilizan, implica todo un proceso de gobierno del ciclo de vida de las distintas APIs, control de los cambios, y adicionalmente la gestión de la Autenticación de los consumidores, el control de la Autorización de uso del recurso que se pretende acceder y por su puesto la Auditoría de las operaciones realizadas lo cual no es muy diferente de los requisitos que pedimos a un API pública.

Advertisements

La era de las APIs públicas

Después de describir las Web APIs en mi anterior post, deje pendiente por analizar distintas visiones que están teniendo lugar en el espacio de las APIs, principalmente en la dicotomía APIs publicas / APIs privadas.

Definía un Web API, no solo cómo el conjunto de funciones y procedimientos que permiten manejar los objetos de negocio, sino además todos aquellos otros elementos alrededor del API en sí misma que permiten su gobierno, el control de los accesos y la seguridad en sí misma sobre dichas funciones y procedimientos.

Por extensión de un Web API, un Web API pública es aquella Web API que expone los objetos de negocio a la comunidad de desarrolladores de internet, es decir, potencialmente a toda la comunidad de desarrolladores.

Habitualmente es necesaria una gestión de esta comunidad de desarrolladores de forma que se tenga un gobierno de los diferentes desarrolladores, así como las apps o mashups que desarrollan, en definitiva de los clientes de nuestra API pública. De esta forma podemos saber cuáles son los usos más comunes, y así progresar el desarrollo de nuevas versiones teniendo en consideración esos usos.

Una API pública puede ser usada por cualquiera para acceder a los métodos de los objetos internos de negocio, solo debe tener un token de identificación de desarrollador, lo cual dependiendo del negocio en sí mismo puede crear un conflicto, ya que como veremos a continuación lo genial de las Web APIs, permitir que unos sitios web usen recursos de otros y ambos crezcan juntos, también ha desembocado en algunos desencuentros.

Twitter tuvo que cambiar su API pública para que la existencia de aplicaciones de terceros no afectasen a su modelo de negocio.

Netflix ha anunciado que va a retirar su API pública, y solamente un conjunto de desarrolladores que realmente estén aportando valor a su negocio van a tener acceso a la nueva versión del API, que será privada. Veremos más sobre APIs privadas en un próximo post.

Aunque aparentemente podría parecer que exponer un API pública podría ser sólo fuente de desencuentros, es también una gran fuente de ventajas. Es el caso de American Express, que expone un API pública para la realización de pagos con puntos de su programa de fidelización (Amex Points), un uso insospechado para American Express de esta API era la posibilidad de pagar con Amex Points en la archiconocida Uber con el incremento en el número potencial de pagos a través de este API pública.

La discusión es si las APIs públicas están en vías de desaparecer, y estamos en el fin de una era, o si se impone un cambio de modelo. Seguiré ahondando en esto en el próximo post.

IoT ya no es el futuro, el futuro está aquí

Leyendo sobre Internet Of Things (IoT), internet de las cosas, me viene a la memoria todo aquello que ya dijimos sobre el futuro hace no tanto. Como que en el año 2000 todos iríamos en coches voladores, usaríamos trajes brillantes, o similares.

Y la cuestión es si, ¿estamos esta vez en la misma tesitura con los 25 billones (americanos imagino) de dispositivos conectados en 2015 que Cisco prevé? . Ejem, y para 2020 Gartner prevé 26, mientras Cisco ya va por los 50 billones.

Si que parece que millón arriba, millón abajo, la idea cuaja y que cada vez una proporción mayor de los dispositivos están conectados a la red de redes, construyendo así una red de cosas, incluso algún avezado hacker ya añadió a su red de dispositivos (BotNet) un frigorífico para hacer algún tipo de ataque DDoS.

Leo en Forbes, y me gusta, acerca de distintas aplicaciones médicas para un internet de las cosas, una red en la que los elementos cotidianos que tenemos nos envían mensajes de distintos tipos.

  • Inyector de insulina que me avise cuando me toca la próxima inyección, o que lleve la cuenta de las que me he ido poniendo.
  • Monitores de bebés, tener una cosa en internet que me avise de que mi peque está teniendo dificultad para respirar, o que tiene fiebre me parece algo tan necesario, y sobre todo, que me avise a mi móvil en vez de a este dispositivo que nunca sé donde enchufar.
  • Gestor de pastillas, un gadget que se me antoja necesario para una población cada vez más necesitada de medicamentos, y cada vez más enganchada a internet. Aunque el invento en sí es una pastilla que ella sola informa de su ingestión, el hecho de que mi gestor de pastillas me avise que hace unas horas que no lo abro, cuando debería haber tomado mi dosis de antibiótico me parece muy útil también.

Y seguro que muchos más gadgets y aplicaciones para asistencia, pero sobretodo un eficaz sistema de Web APIs con el que poder controlar y gestionar los datos privados de estas herramientas tan personales, así como controlar los accesos a estos nuevos gadgets, y la información que proporcionan.

Otra de las cuestiones importantes, es de si es posible generar las APIs que deben ser consumidas por las aplicaciones finales, que normalmente se van a encontrar en la palma de la mano del usuario final [móvil, tablet, phablet, …], y que deben proveer el necesario control y gobierno, así como la protección frente a los ataques más rabiosos.

Disponer de una adecuada estrategia de gestión de APIs, con la necesaria seguridad, es posible y controlar las apps que están consumiendo las APIs expuestas, así como los procesos empresariales subyacentes, es hoy en día una realidad más allá de los sueños más futuristas que tuviéramos en los 80.