En estas dos últimas semanas se ha multiplicado el número de personas que me han preguntado qué es una API, y no me extraña, lo que podemos leer en la Wikipedia o en otros sitios especializados contiene un lenguaje muy técnico que hace que la mayor parte de la gente no se aclare. Aquí voy a tratar de explicarlo de forma sencilla, para que lo podamos entender todos.
Una API es una puerta que nos permite acceder a los recursos disponibles en una aplicación informática. API viene del inglés Application Programming Interface, que significa "interfaz programable de la aplicación"
Uno de esos "recursos" por ejemplo en la API de Twitter sería "dame una copia del último tweet del usuario x")
Las API tienen que documentarse para que podamos conocer los métodos que deben utilizarse.
Por ejemplo, este link devuelve una lista de usuarios en un formato programable, es decir, que puede ser leído y procesado por otra aplicación:
https://jsonplaceholder.typicode.com/users
Pero si leemos la documentación sabremos que añadiendo un número al final, nos devolverá solo al usuario que tenga ese número de identificación. Hagamos la prueba:
Como hemos usado un link de la API, la web entiende que no somos una persona, sino otra aplicación, y nos devuelve los datos en un formato apto para ser procesado por computadoras.
Hace tiempo que la web dejó de ser una gran masa de páginas y contenidos enlazados entre sí mediante links. Los desarrolladores enlazan también funcionalidades y datos entre un sitio y otro y para ello se valen de la API del sitio con el que quieren interactuar. Si una aplicación tiene una API, quiere decir que no sólo se puede interactuar con ella a través del teclado y el ratón, sino que existe la posibilidad de enviarle órdenes de forma automática utilizando su API. Con este sistema de APIs ahora tenemos una web programable que permite a nuestros desarrolladores el acceso a una creciente gama de servicios que pueden consumir ellos mismos o que incluso pueden ofrecer a sus usuarios como si fueran propios.
Alguno de los primeros servicios a los que se podía acceder en la web de esta forma, sin intervención humana, fueron los que publicaban tipos de cambio de divisas o cotizaciones de bolsa. Desde nuestra página web podíamos crear un link especial hacia esa web, que al ser pulsado devolvía a nuestro visitante el precio al que estaba en ese momento el dolar. Nuestro visitante entonces pensaba que esa información estaba en nuestro servidor, pero nada más lejos de la realidad...el dato en cuestión viajaba desde otro servidor situado en EEUU, pero a una velocidad que le hacía pensar que salía de nuestra misma página.
Esta forma de intercambio de información entre sistemas informáticos ha existido siempre, pero entonces "los enchufes" se tenían que hacer a la medida cada vez que queríamos interoperar con otro servidor. A diferencia de lo que ocurre con la evolución de las especies animales, aquí finalmente no triunfa el más fuerte sino el más simple. Los grandes intentos por estandarizar esos enchufes, como fueron CORBA o SOAP se cambian progresivamente en favor de formatos más sencillos que todo el mundo puede usar sin demasiados conocimientos técnicos, como es el popular método REST, acrónimo de Representational State Transfer, y mediante el cual podemos acceder a la mayor parte de los servicios que hoy día se exponen en la web. Lo sencillo vuelve a triunfar una vez más.
Por el camino han quedado toda una serie de formatos o "enchufes" que en cierta forma me recuerdan a ese cajón que solemos tener en casa lleno de cargadores de teléfonos móviles... todos hacen lo mismo y funcionan, pero ninguno nos sirve ahora.
La popularidad de este método REST para intercambiar información y ofertar funcionalidades ha alcanzado ya una masa crítica que hará que el uso de este tipo de servicios se dispare en los próximos años. Todos los sitios web tendrán una API o harán uso de ella. Formularios, bases de datos, backups, CRMs, facturación, validación de datos, portales, call centers, feedback, ...todos estos servicios necesitan trabajar coordinados, con datos sincronizados en tiempo real, sobre diferentes aplicaciones y sistemas, y todo ello por Internet. Esto sólo es posible con un denso tramado de APIs de calidad. Es ahí a donde vamos y es a ese escenario que veremos generalizado dentro de pocos años.
Estos cuatro son los responsables de la enorme difusión de esas APIs. Cuando el desarrollador de un servicio web tipo Flickr o Picasa, o de una aplicación de CRM como Salesforce quiere que los datos o las funcionalidades se puedan manipular desde otra aplicación, debe definir qué recursos estarán expuestos y de qué forma se accederá a ellos.
Un ejemplo: si quiero abrir una nueva línea de negocio añadiendo una aplicación de comercio electrónico a mi comercio tradicional, debería seleccionar una con la que pudiera comunicarme, es decir, que tenga una API, y que esa API me deje, por ejemplo, actualizar las cantidades en stock de forma automática desde la aplicación que ahora utilizo para gestionar mi almacén.
Para hacernos una idea de qué significa ésta nueva arquitectura de la web, bastará el ejemplo del explosivo crecimiento de Twitter. Twitter tiene una de las APIs más utilizadas de la web. Sobre esa API, otros construyeron servicios que han multiplicado la presencia de Twitter en todo tipo de plataformas móviles, una expansión que ellos solos nunca hubieran logrado, o al menos no lo hubieran logrado tan rápidamente. Incluso su servicio de búsquedas, el que ahora utilizan, lo adquirieron a un tercero que lo había programado utilizando la propia API de Twitter. Los programadores de Twitter no fueron capaces de hacer algo tan bueno para ellos mismos, pero al exponer su API a todo el mundo, los programadores de otras aplicaciones empezaron a usarla. Así es como apareció alguien que fue capaz de crear un sistema de búsquedas para Twitter mejor que el del propio Twitter.
Klout es otro de esos servicios en auge que también usan la API de Twitter. Ellos a su vez publican su propia API que nos da una categorización y valoración pormenorizada de la actividad de los usuarios de Twitter.
El caso de Facebook es otro ejemplo paradigmático. Facebook empezó publicando una API para que otros desarrolladores pudieran ofrecer servicios dentro de Facebook. Ése es el caso de Zynga, un desarrollador de juegos para Facebook, que ha levantado nada menos que un billón de dólares americanos en su reciente salida a bolsa.
Ahora Facebook ha dado un paso más, esta vez para extender sus tentáculos por toda la web. Con nuestros "me gusta" y comentarios que hacemos en algunos sitios, recogen a través de su API una valiosa información que luego explotan en su red social. Ya no tienes que entrar en facebook.com para publicar comentarios, es Facebook quien te sale a buscar fuera.
Este mundo de las APIs es relativamente nuevo aunque ya empezó hace unos diez años. Recuerdo una presentación que hice a finales del 2001 en el Comité de Investigación en Tecnologías de la Información (CITI) en donde estaban las grandes del IBEX para presentarles como gran novedad la API creada para un servicio web que gestiona información e imágenes de productos de gran consumo. Aquella API la habíamos desarrollado con SOAP, un sistema como REST, pero que documenta la API de forma que la propia descripción de los métodos y recursos pueda ser leída por una máquina. Sin embargo desde entonces REST ha ido ganando terreno y popularidad, tal y como nos muestra el gráfico que recientemente ha publicado programmableweb.com, la web de referencia para este tipo de servicios.
Conclusión
Creo que es fácil ver el profundo cambio que esto tendrá sobre la forma en la que ahora diseñamos nuestras estrategias, los servicios o las campañas que hacen uso de datos y aplicaciones. Con este post espero haber aclarado qué son las APIs y por qué son importantes para las empresas que necesitan competir en una economía abierta y en contínua transformación.
Post modificado el 26/05/2019 para actualizar links
