¿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.

API Management y OpenData

Son tantos los entornos, los usos, que se han hecho de la célebre frase “ … connect the dots …” que me parece abusar. Es cierto que el contexto me parece perfecto en mi caso, en el que tuve una pequeña exposición a open-data, smartcities, hace algún tiempo y es ahora que mi interés está más cercano al API Management, que una chispa, un comentario en una reunión,  me acercó a conjuntar ambos elementos.

Es más, leo un post muy interesante de Mark Boyd (@mgboydcom), http://blog.programmableweb.com/2013/10/24/government-open-data-how-to-get-involved/,  en el que ciertamente termino por cerrar el círculo de la importancia de unir ambos conceptos.

{"topic":"OpenData"}

Para poder exponer aquellos datos que las diferentes agencias gubernamentales publican, de forma que podamos consumirlos desde cualquier página o app, es importante tener ciertos aspectos en cuenta:

  • Formato de la información: habitualmente csv, excel, html, pero también json, txt, kml, xml, georss, rdf, entre tantos otros.
  • Adquisición de la información: atendiendo a los criterios de actualización de las fuentes, unas serán cuasi automáticas y otras contienen datos históricos sin mucha frecuencia de actualización.
  • Uso de la información: quizá el aspecto más complejo, y sobre el que quería centrarme ya que esta información puede ser expuesta no solo en distintos formatos, sino también relacionada con otras informaciones, o enriquecida por los ciudadanos.

El uso de la información opendata, una vez queremos exponerla con nuestro propio “toque”, nos permite publicar apps y exponer servicios en los que podemos aportar valores añadidos:

  • Enriquecimiento de la información con otras APIs, o servicios, tanto públicos como privados que permitan no solo contextualizar la información en un área geográfica, sino relacionarla con otra información como la previsión del tiempo o la concentración de agentes microscópicos (polen, partículas, gases).
  • Información personalizada por usuario, o localización del usuario, de forma que acercar la información pública a la palma de la mano del ciudadano le reporte un beneficio tangible en el día a día.
  • Abrir la posibilidad a un usuario de enriquecer la información provista, es muy común el caso en entornos de smart-cities de la notificación de los ciudadanos sobre elementos del mobiliario estropeados o incluso información sobre el tráfico, atascos y obras la lista se me antoja infinita.

Ante lo que es también importante disponer de ciertas capacidades:

  • Mediación, disponer de las capacidades necesarias para poder expresar la información abierta u open-data, en cualquiera de los formatos en los que se encuentre, de forma que sea comprensible por los dispositivos donde vaya a ser consumida, principalmente JSON utilizando el paradigma REST.
  • La nube, ser capaz de acceder a la información pública en distintos formatos, mediante protocolos como http/s no es un hándicap hoy en día. Si es cierto que es necesario disponer de las capacidades de exponer servicios o web APIs sobre este open-data, en la nube con los requisitos de crecimiento elástico necesarios para crecer si se produce un efecto viral, o simplemente porque nuestro servicio es un servicio de éxito.
  • Gestión de identidad, donde no solamente es importante la gestión de la autenticación de usuarios sino la posibilidad de utilizar identidades federadas en terceros y autenticar utilizando protocolos y tecnologías como OpenID entre otras.
  • Frontal de seguridad, merece quizá una serie de capítulos completos en los que evaluar las distintas posibilidades de securización, control de amenazas, gestión de ataques (ddos, code inyection,…) .
  • Monitorización y control, los elementos que suelen darse por supuestos y que marcan la diferencia en un entorno productivo en el que es imprescindible tener claro cuáles de los servicios expuestos están siendo consumidos y cómo lo están siendo, emitiendo las alertas pertinentes en el caso de que alguno de los SLA definidos hayan sido sobrepasados.

En definitiva, las Web APIs permiten la aproximación del ciudadano a los datos abiertos, opendata, en los dispositivos que éste tiene en la palma de la mano.

Así mismo es posible un enfoque desde el punto de vista profesional del consumo de datos, protección de infraestructuras, mash-up de servicios y oferta de servicios tanto en formatos free APIs como freemium. Lo que indudablemente añadirá más competición a la explotación de datos, que no olvidemos son de todos porque todos los pagamos, y la obtención de valor de estos bienes comunes.