Qué es una API y por qué decide si tus sistemas hablan entre ellos

Pides el salmón. No entras en la cocina a explicarle al cocinero qué sartén usar ni a qué temperatura, ni le preguntas de qué proveedor viene el pescado. Le dices «salmón», él sabe lo que tiene que devolverte, y confías en que lo que te traigan sea justo lo que la carta prometía. No necesitas saber cocinar para pedir bien. Solo necesitas la carta.

Eso —pedir algo de una lista conocida, sin ver ni tocar cómo se prepara por dentro, confiando en que el resultado cumpla lo pactado— es exactamente lo que hace un programa cuando le pide información o una acción a otro programa. A esa carta, en software, se le llama API.

#La carta como contrato

Una API (siglas en inglés de «interfaz de programación de aplicaciones») es, en esencia, la lista de cosas que un sistema deja pedir a los demás, y cómo hay que pedirlas. Igual que la carta de un restaurante no te enseña la cocina, una API no te enseña el código de dentro: te enseña qué puedes pedir —«dame los datos de este cliente», «crea una reserva nueva», «marca este pedido como enviado»— y qué te va a devolver a cambio.

Esa lista es un contrato, aunque nadie la llame así en la reunión de venta. Si tu sistema de reservas publica una API que promete «puedes pedir el listado de reservas de un día concreto», cualquier otro programa que confíe en esa promesa puede construir algo encima sin miedo, sabiendo que ese pedido va a seguir funcionando igual mañana y dentro de un año. El día que esa promesa cambia sin avisar —el plato desaparece de la carta, o llega distinto de como lo prometía— todo lo que se apoyaba en ella se rompe a la vez, y casi nunca es culpa de quien lo construyó encima.

Hay una segunda ventaja en esta forma de trabajar, y suele pasar desapercibida: mientras la carta no cambie, al proveedor le da igual reformar la cocina entera por dentro. Puede cambiar de sitio los fogones, sustituir una máquina por otra o reorganizar el almacén, y a ti, que solo pides de la carta, no te afecta en nada. Esa es la razón de fondo por la que una buena API separa lo que un sistema promete de cómo lo cumple por dentro: permite mejorar un lado sin arriesgar el otro.

#Por qué esto es dinero, no una cuestión técnica

Aquí es donde deja de ser un detalle de programadores y pasa a ser una decisión de negocio. Piensa en una sala de conciertos que vende entradas por su cuenta y que además quiere que esas ventas aparezcan solas en su contabilidad, en su herramienta de email para avisar a los compradores, y en un panel donde el equipo ve cuánto se ha vendido hoy.

Si el sistema de venta de entradas tiene una API bien hecha, esas tres cosas pasan solas: cada venta nueva se puede pedir automáticamente y llevar adonde haga falta, en segundos, sin que nadie la toque a mano. Si no la tiene —o la tiene, pero mal documentada, o cerrada—, la única forma de mover esos datos de un sitio a otro es que alguien del equipo abra un archivo, lo descargue, y lo copie a mano en el otro sistema. Cada día. Sin fallar nunca, porque un solo despiste desajusta la contabilidad, el email o el panel.

Llamar a eso un inconveniente menor se queda corto: es trabajo humano recurrente pagando por hacer lo que un programa podría hacer solo, con el riesgo añadido de que las personas se equivocan copiando números y los programas, si están bien hechos, no. Y el problema no se limita al primer sistema que conectes: una tienda con web y local físico que quiere unir su catálogo, su facturación y su envío de correos a clientes va a necesitar tres conexiones, no una, y cada una de ellas depende de si el sistema del otro lado tiene o no tiene esa carta publicada.

#Antes de firmar con un proveedor de software, cuatro preguntas

Da igual a qué se dedique el proveedor —venta de entradas, reservas, gestión de clientes, lo que sea—: estas cuatro preguntas se hacen igual en todos los casos, porque la respuesta determina si en el futuro vas a poder mover tus propios datos con libertad o vas a quedarte atrapado copiando a mano:

• ¿Tiene API? Si la respuesta es «no, pero se puede exportar un archivo», entiende que cualquier conexión automática con otro sistema va a costar más trabajo, o va a ser directamente imposible sin ayuda del proveedor.
• ¿Está documentada? Una API sin documentación es una carta escrita en un idioma que solo conoce quien la escribió. Existir no basta: alguien de fuera tiene que poder entender qué pedir y qué esperar a cambio sin llamar cada vez al proveedor original.
• ¿Me la dais sin coste adicional? Esta es la pregunta que más dinero ahorra a medio plazo, y la siguiente sección explica por qué.
• ¿Qué pasa si algo de esto cambia? Si el proveedor no tiene una respuesta clara, asume que un día cambiará sin avisarte con tiempo.

#El caso frecuente: «sí tenemos API» con letra pequeña

Es habitual oír «claro que tenemos API» en una reunión de venta, y descubrir después que esa API existe, sí, pero viene con condiciones que nunca se mencionaron: un coste mensual aparte solo por usarla, un límite de peticiones al mes que se agota rápido si tu negocio crece, o una versión reducida que deja fuera justo los datos que necesitabas mover.

Un ejemplo habitual, con cifras solo ilustrativas para que se entienda la forma: el proveedor incluye 1.000 peticiones gratuitas al mes, cantidad que parece generosa el primer mes de uso y se queda corta en cuanto el negocio crece y esas peticiones se multiplican. A partir de ahí, cada petición extra se cobra aparte. Nadie mintió al decir «tenemos API». Simplemente no se detalló el límite hasta que ya dependías de ella para funcionar.

Ninguna de esas tres cosas es ilegítima por sí sola —mantener una API cuesta dinero al proveedor, y es razonable que lo cobre de algún modo—. El problema es descubrirlo después de firmar, en vez de antes. Pedir por escrito, antes de contratar, qué incluye exactamente el acceso a la API y qué no, evita la sorpresa de un coste nuevo que aparece justo cuando ya dependes de ese sistema para funcionar.

#Que una API «rompa» y por qué las versiones importan

Cuando alguien dice que «la API se ha roto», no significa que algo esté averiado por accidente. Casi siempre significa que el proveedor cambió la carta sin avisar: renombró un dato, dejó de devolver un campo que antes venía incluido, o cambió la forma de pedir algo que antes se pedía de otra manera. Todo lo que confiaba en la carta anterior deja de funcionar de golpe, aunque nada estuviera roto de verdad en tu sistema.

Por eso las APIs serias se publican con número de versión —«versión 1», «versión 2»— y por eso ese número importa más de lo que parece. Una API que anuncia una versión nueva sin retirar la anterior te está dando tiempo: puedes seguir pidiendo por la carta vieja mientras alguien migra tranquilamente a la nueva, en vez de despertarte un día con todo roto sin previo aviso.

#La cláusula que conviene pedir en cualquier contrato de software

Si vas a contratar un sistema que en algún momento va a tener que hablar con otro —y casi todos, tarde o temprano, tienen que hacerlo—, pide por escrito que el contrato recoja tres cosas: que el acceso a la API está incluido en el precio que ya pagas, que cualquier cambio que rompa lo existente se avisará con un plazo mínimo razonable, y que la versión que usas hoy seguirá funcionando durante ese plazo aunque salga una nueva. Esas tres garantías se piden por escrito y se comprueban después; no requieren que entiendas una sola línea de código.