Una interfaz de programación de aplicaciones, conocida como API por sus siglas en inglés, es un conjunto de reglas, mecanismos y especificaciones que permite que un programa de software solicite datos o servicios a otro programa sin tener que conocer cómo funciona internamente. La API define qué se puede pedir, cómo debe hacerse la solicitud y, en términos generales, qué tipo de respuesta se recibirá.
En este intercambio suele haber un cliente, que solicita algo, y un servidor o servicio, que procesa la petición y responde. La API funciona como una especie de contrato entre ambos. Por ejemplo, cuando abres una aplicación del clima en tu teléfono, la aplicación normalmente no contiene por sí misma todos los datos meteorológicos que necesita. Puede solicitar información a un servicio externo mediante una API, recibir los datos correspondientes y presentarlos de una manera sencilla en la pantalla. Para ti, el proceso parece inmediato: abres la aplicación y ves la temperatura, la probabilidad de lluvia o el pronóstico.
Con el desarrollo de los sistemas operativos y, más tarde, de las redes y de internet, las interfaces entre programas adquirieron una importancia cada vez mayor. En la actualidad, muchas APIs permiten que sistemas que se encuentran en computadoras diferentes se comuniquen a través de una red. Las llamadas APIs web suelen utilizar HTTP, el protocolo que también interviene en la comunicación entre los navegadores y los servidores web, aunque una API no tiene que utilizar necesariamente HTTP.
Un ejemplo muy cotidiano aparece cuando compras algo por internet y eliges pagar mediante un proveedor externo. La tienda puede enviar una solicitud al sistema de pagos a través de una API. El servicio procesa la operación y devuelve una respuesta que indica, por ejemplo, si el pago fue autorizado o rechazado. La tienda puede entonces mostrarte el resultado. Esto permite que el comercio utilice servicios especializados sin tener que construir desde cero toda la infraestructura necesaria para procesar pagos.
Las APIs también están detrás de muchas funciones que utilizamos sin pensar demasiado en ellas. Cuando un sitio permite iniciar sesión mediante una cuenta de un proveedor externo, cuando una aplicación muestra mapas proporcionados por otra compañía o cuando un servicio incorpora información de transporte, clima o geolocalización procedente de otra plataforma, es posible que existan APIs haciendo posible esa integración. La gran ventaja es que los desarrolladores pueden aprovechar capacidades que ya existen y concentrarse en aquello que hace diferente a su propio producto.
Esta separación también puede mejorar la seguridad y facilitar el mantenimiento, aunque una API por sí sola no garantiza que un sistema sea seguro. Una interfaz bien diseñada puede limitar qué operaciones y datos están disponibles para los usuarios o aplicaciones autorizadas, mientras mantiene ocultos muchos detalles internos. Además, si el sistema que está detrás de la API cambia su implementación interna, pero conserva el contrato que los clientes utilizan, las aplicaciones que dependen de ella pueden continuar funcionando sin necesidad de conocer esos cambios.
Las APIs pueden adoptar diferentes estilos y tecnologías. SOAP, por ejemplo, fue ampliamente utilizado para servicios web y suele emplear mensajes XML con estructuras muy definidas. REST, por otro lado, se convirtió en uno de los enfoques más populares para diseñar APIs web y aprovecha conceptos de HTTP. Muchas APIs REST utilizan JSON para intercambiar información porque es relativamente compacto y sencillo de procesar. También existen alternativas como GraphQL, que permite que el cliente especifique con mayor precisión qué información necesita, y WebSockets, que permiten mantener una comunicación bidireccional y continua, algo especialmente útil en aplicaciones que requieren actualizaciones en tiempo real. Conviene aclarar que REST, GraphQL y WebSockets representan enfoques diferentes para resolver necesidades de comunicación entre sistemas.
Las empresas también pueden clasificar sus APIs según quién tiene acceso a ellas. Una API privada puede utilizarse exclusivamente dentro de una organización para conectar sus propios sistemas. Una API para socios puede estar disponible para empresas con las que existe una relación comercial específica. Una API pública puede ofrecerse a desarrolladores externos, aunque “pública” no significa necesariamente que sea gratuita ni que cualquiera pueda utilizarla sin restricciones. Puede requerir una cuenta, una clave de acceso, autenticación, límites de uso o incluso un pago. Esta posibilidad de ofrecer capacidades tecnológicas como servicios reutilizables contribuyó al desarrollo de lo que suele denominarse economía de las APIs.
La historia reciente de internet ofrece ejemplos que muestran hasta qué punto estas interfaces pueden convertirse en piezas fundamentales de una plataforma. Twitter, durante sus primeros años, construyó una importante comunidad de desarrolladores externos alrededor de su API. Muchas aplicaciones podían utilizar los servicios de Twitter para crear experiencias alternativas. La enorme cantidad de aplicaciones y solicitudes también generó problemas de escala y llevó a la plataforma a modificar progresivamente sus políticas, límites y condiciones de acceso. Con el tiempo, Twitter —posteriormente X— redujo de manera considerable el acceso de terceros, hasta llegar a restricciones mucho más severas.
Las APIs también se han convertido en un asunto fundamental de ciberseguridad. Una aplicación puede tener una API perfectamente funcional y, al mismo tiempo, estar mal protegida. Un ejemplo es la vulnerabilidad conocida como BOLA, sigla de Broken Object Level Authorization. Puede aparecer cuando un sistema permite que un usuario modifique un identificador dentro de una solicitud y, debido a una autorización deficiente, consiga acceder a un objeto que pertenece a otra persona. Una API debe comprobar no solo si una solicitud está bien formada, sino también si quien la realiza tiene permiso para acceder al recurso solicitado.
Otro episodio que mostró el poder de las APIs ocurrió en Reddit en 2023. La plataforma anunció cambios importantes en las condiciones económicas de acceso a su API. El aumento de los costos puso en dificultades a varias aplicaciones de terceros, entre ellas Apollo. La reacción de numerosos moderadores y comunidades desembocó en un apagón coordinado de subreddits durante junio de 2023. El caso se convirtió en un ejemplo especialmente claro de cómo las decisiones sobre una API pueden afectar a desarrolladores, moderadores y usuarios finales.
La importancia de una API también puede observarse cuando se produce un cambio incompatible. Supongamos que una aplicación espera recibir un campo llamado “precio” y el proveedor lo elimina o cambia su significado sin mantener compatibilidad. La aplicación podría dejar de funcionar correctamente. Este tipo de modificación rompe las expectativas establecidas por el contrato anterior. Por eso, las APIs profesionales suelen utilizar versiones, políticas de compatibilidad, documentación, pruebas y mecanismos de transición para reducir el riesgo de afectar a quienes dependen de ellas.
Durante la pandemia también aparecieron numerosos proyectos curiosos que combinaban APIs y datos externos para resolver problemas cotidianos, desde aplicaciones relacionadas con el clima hasta herramientas para cocinar.
Una tendencia que tiene gran relevancia en el desarrollo actual es el enfoque conocido como “API First”. La idea consiste en diseñar primero las interfaces mediante las cuales distintos componentes y clientes utilizarán una capacidad del sistema, en lugar de construir una aplicación y pensar después cómo exponerla. Esto puede facilitar que una misma lógica de negocio sea utilizada desde un teléfono, una página web, un automóvil, un reloj inteligente u otros dispositivos. La interfaz de comunicación se considera una pieza fundamental del diseño desde las primeras etapas.
Gracias a las APIs, los desarrolladores pueden reutilizar capacidades, conectar servicios, crear nuevos productos y automatizar procesos a una escala que sería imposible si cada aplicación tuviera que construir todo desde cero.
Referencias: