Porqué las APIs no bastan

El advenimiento de la Web ha permitido no sólo la publicación global de documentos, sino que poco a poco ha provisto un ecosistema de interconexiones con distintos propósitos. Uno de ellos ha sido la conexión remota entre aplicaciones, vía interfaces llamadas APIs, acelerando y facilitando enormemente el desarrollo de nuevas aplicaciones.

En este artículo les quiero contar por qué creo que el uso de APIs es, en muchos casos, insuficiente.

¿Qué es una API?

Una Application Programming Interface (API para los amigos) es, como dice su nombre, una interfaz que permite acceder a un conjunto de servicios de manera programática, es decir, sin la intervención de un ser humano. El establecer APIs claras permite que diversas aplicaciones puedan "conversar" entre ellas. Por ejemplo, la aplicación que controla mi calendario tiene una API que permite que mi cliente de correo pueda agregar reuniones, citas, etc. Asimismo, el sistema de notificación del sistema operativo posee una API que permite que mi aplicación de calendario pueda levantar una ventanita avisándome de mi próxima reunión.

En un ambiente colaborativo como la Web, es natural que aparezcan estas APIs que permiten a diversos sistemas interactuar entre ellos. Sólo para tener una idea, de acuerdo a Programmable Web, hay 2.284 APIs registradas actualmente en su sitio web (aunque deben haber muchas más).
Utilizando estas APIs es posible construir nuevas aplicaciones que utilicen los servicios que ellas proveen: Por ejemplo, una API X, puede proveer una funcionalidad que me permita calcular la suma 2 números, mientras que otra provee la resta, una tercera provee multiplicación, etc. Así, puedo crear una nueva aplicación que haga de calculadora, sin necesidad de programar cada operación matemática, sino simplemente invocando la API correspondiente. También es posible pensar en que una biblioteca provea una API con un listado de los libros que posee, cuáles están disponibles, etcétera.

Si son tan buenas, ¿Por qué no bastan?

Hasta ahora he contado maravillas sobre las APIs, sin embargo, ellas tienen un problema fundamental: Al momento de diseñar una API se está restringiendo la forma y el tipo de contenido que se puede obtener. En el caso de la biblioteca, imaginemos que la API permite obtener el nombre del libro, el autor y si acaso está disponible para préstamo o no. ¿Qué pasa si queremos acceder a la editorial? ¿Y el año de publicación? (suponiendo que la biblioteca posea esa información). Una posible respuesta es que sólo es necesario agregar más funcionalidades a las API (por ejemplo, buscar por año, por editorial, etc). Esto no sería problema para una pequeña biblioteca, sin embargo hay dos tendencias que hacen que esto no sea sostenible: El aumento de datos y The Long Tail.

The Long Tail

Una tendencia recurrente en muchos aspectos de la Web es que su organización es basada en una distribución de Pareto (la famosa regla del 80-20). Así por ejemplo, uno puede imaginar que con nuestra API de biblioteca (que entrega nombre de libro, autor y si está disponible o no) dejamos contentos al 40% de nuestra audiencia. Pero quedamos con un 60% insatisfecho (20% quieren el año de publicación, 20% quieren la editorial, 15% quiere el ISBN y 5% quiere la carátula). ¿Cómo satisfacer a este 60% de potenciales usuarios de nuestros datos donde cada uno tiene requerimientos específicos para sus nichos (los cuales son muy pequeños como para que importen individualmente, pero son críticos como grupo). Peor aún es que a medida de que tenemos más y más datos (carátula del libro, keywords, categorías, etc.) el mantener más y más funcionalidades en una API se vuelve muy complicado.

Por ejemplo, he escrito en varias ocasiones en cómo el gobierno debiese publicar datos de manera abierta. ¿Alguien espera que exista una API (o una función dentro de ésta) por cada tipo de datos único? ¿Cómo manejar cientos de miles de datos de minería, pesca, educación, etc.?

Cómo la Web Semántica puede ayudar

Una de las alternativas es usar un SPARQL endpoint, que es una interface en la Web que permite ejecutar consultas en SPARQL, el cual es un lenguaje similar a SQL (el lenguaje más popular para consultar bases de datos). Esto le da la flexibilidad a los desarrolladores de aplicaciones de obtener los datos que ellos necesiten y no sólo los provistos por una API predefinida. Así, una posible solución consiste en proveer un SPARQL endpoint al mismo tiempo que las APIs ya existentes. Por ejemplo, si sólo necesito el nombre de un libro y el autor, me conviene usar la API. Sin embargo, si quiero algo más complicado como "autores cuyos nombres empiecen con la letra A y hayan escrito un libro antes de 1980", utilizaré el endpoint. Es decir para todo lo demás, existe SPARQL.

¿Cuáles serían los beneficios?

Desde el punto de vista de las instituciones que proveen estos servicios, los beneficios son múltiples: En primer lugar, disminuyen el costo de mantención de múltiples funcionalidades, permitiendo a los proveedores de estás APIs mantener sólo ciertas operaciones básicas. En segundo lugar, se le da mayor valor a los datos, ya que facilita su reutilización en formas impensadas por los diseñadores de las APIs (además que les hace la vida más fácil a los desarrolladores, lo que siempre es bueno :-P). Tercero, al usar un SPARQL endpoint, estamos aceptando el uso de estándares que facilitan la integración de nuestros datos con los de otros servicios, potenciando a los desarrolladores para crear aplicaciones más ricas que si sólo utilizaran nuestros datos. En cuarto lugar, existen instituciones para las cuales es importante abrir, publicar y compartir sus datos de la forma más abierta posible. El ejemplo obvio es el gobierno, pero existen muchas motivaciones para que los privados hagan esfuerzos similares, tema del que hablaré más adelante.

Entonces, ¿Eliminamos las APIs?

Soy un convencido de que "one size doesn't fit all" y eso aplica para cualquier tecnología. Hay probablemente muchos casos donde los datos disponibles son tan simples que el uso de un SPARQL endpoint no se justifica, y una API con unas pocas funcionalidades básicas será más que suficiente. Sin embargo, mi hipótesis es que estos serán cada vez casos más y más aislados: La información que las organizaciones manejan (tanto en cantidad como en tipo de datos) va creciendo rápidamente, por lo que se hará cada vez más necesario darle el poder a los desarrolladores de obtener los datos que ellos necesitan de la forma que ellos consideren más conveniente. Asimismo, el uso de tecnologías semánticas hace más fácil el utilizar datos de distintas fuentes.

Imagenes: Diagrama dist. pareto vs normal, Archimides Lab, Logo Sparql @ Semantic School.