¿Qué es una API (interfaz de programación de aplicaciones)?

Las API exponen solo los datos y la funcionalidad necesarios para una interacción específica, manteniendo ocultos otros detalles internos de implementación. Esta abstracción protege la integridad del sistema y simplifica la forma en que se comunican los componentes de software.

Hay muchos tipos de API (API de hardware y firmware, API del sistema operativo, API de biblioteca y marco, API web y más) y, a un nivel general, todas funcionan de la misma manera: definen un contrato entre dos piezas de software, especificando qué se puede solicitar y devolver.

Como artículo explicativo centrado en la integración, este artículo se centra principalmente en las API web (un tipo de API que permite al software realizar solicitudes a través de una red, a menudo utilizando HTTP), cómo funcionan, sus diferencias y cómo se utilizan para conectar sistemas, sincronizar datos y automatizar los flujos de trabajo.

Es útil pensar en la comunicación de la API en términos de solicitud y respuesta entre un cliente y un servidor. La aplicación que envía la solicitud es el cliente y el servidor proporciona la respuesta. La API define los términos de comunicación entre ellos.

Como ejemplo sencillo, consideremos el procesamiento de pagos de terceros. Cuando un usuario compra un producto en un sitio de comercio electrónico, el sitio puede ofrecer la opción de "Pagar con PayPal". Esta función se basa en API para esta conexión.

• Cuando el comprador pulsa el botón de pago, se inicia una llamada API. Esta solicitud se procesa desde una aplicación al servidor web a través del identificador uniforme de recursos (URI) de la API e incluye un verbo de solicitud, encabezados y, a veces, un cuerpo de solicitud. Juntos, especifican qué se solicita y cómo.
  
  
• Después de recibir una solicitud válida del cliente, la API reenvía la solicitud al programa externo o servidor web (en este caso, el sistema de pago de terceros) y devuelve una respuesta con la información solicitada.
  
  
• La API transfiere los datos a la aplicación solicitante inicial, en este caso, el sitio web del producto.

Para el usuario final, todo este intercambio es invisible: simplemente ve una confirmación de pago exitosa.

Las API existen en todas las capas del software, desde las cercanas al hardware hasta los servicios web con los que la mayoría de la gente interactúa a diario. En muchas conversaciones cotidianas, API se utiliza como sinónimo de API web. Pero hay muchos tipos de API que se adaptan a diferentes casos de uso, entre ellos:

• Las APIs de hardware y firmware permiten que el software se comunique con los componentes físicos de un dispositivo, como procesadores y sensores.
  
  
• Las API del sistema operativo permiten que el software se comunique con los sistemas operativos para servicios como la gestión de archivos, procesos y memoria.
  
  
• Las API de biblioteca y marco exponen código preescrito (funciones, métodos y ganchos) con el que los desarrolladores interactúan directamente dentro de sus aplicaciones, sin pasar por una red. 
  
  
• Las APIs de bases de datos permiten al software comunicarse, manipular y extraer información almacenada en una base de datos.
  
  
• Las APIs web permiten al software realizar peticiones a través de una red, a menudo usando HTTP. Son un tipo de API remota, que facilitan la comunicación y la manipulación de recursos entre diferentes máquinas, en lugar de un solo dispositivo.

*Cabe señalar que algunos sistemas más antiguos exponen protocolos de red (como FTP, SMTP y SSH) directamente como su interfaz de integración. Técnicamente, se ajustan a una definición amplia de API, aunque se clasifican por cómo se comunican, en lugar de con qué interactúan, y son menos pertinentes para una discusión centrada en la integración.

Las API web son las más comunes para integración. A diferencia de los otros tipos de API mencionados anteriormente, están diseñados para la comunicación entre aplicaciones separadas a través de una red.

REST es el estilo arquitectónico dominante de las API web en la actualidad. Las APIs REST, también conocidas como APIs RESTful, se basan en seis restricciones arquitectónicas orientadoras definidas inicialmente por Roy Fielding para la creación de servicios web escalables, flexibles y desacoplados.

REST pone los datos a disposición como recursos, y las API REST utilizan métodos HTTP como GET, POST, PUT, PATCH y DELETE para interactuar con esos recursos. Cada recurso se identifica mediante un URI único, comúnmente denominado endpoint de API. Esta es la dirección específica a la que el cliente envía una solicitud de API.

REST se define por las siguientes restricciones:

• Interfaz uniforme - Crea reglas de comunicación estandarizadas: todas las solicitudes del mismo recurso deben tener el mismo aspecto. Cada recurso debería tener un URI.
  
  
• Separación cliente/servidor - las aplicaciones cliente y servidor deben poder evolucionar por separado, sin dependencias. La única información que tiene el cliente es el URI del recurso.
  
  
• Sin estado - El servidor no almacena el estado de la sesión entre solicitudes. Cada solicitud es autónoma y debe incluir toda la información necesaria para procesarla.
  
  
• Cacheabilidad - Todos los recursos deben ser cacheables cuando sea posible y el servidor debe declarar estos recursos como cacheables.
  
  
• Arquitectura del sistema en capas: dado que cada solicitud en REST es autónoma, el cliente no necesita saber si se está comunicando con el servidor de origen o con un intermediario. Esto hace que REST sea muy adecuado para las API públicas que atienden a muchos clientes.
  
  
• Código bajo demanda (opcional): las API REST suelen devolver datos. Esta restricción final (la única restricción opcional) permite la devolución de código ejecutable, como JavaScript, que el cliente puede ejecutar cuando sea necesario.

Para obtener una explicación más completa de los principios REST, vaya aquí.

SOAP es un protocolo de mensajería basado en XML con estándares estrictos sobre cómo se estructuran y transmiten los mensajes. A diferencia de las API REST, que en la práctica se ejecutan casi exclusivamente a través de HTTP, SOAP es independiente del transporte. Puede funcionar a través de HTTP, SMTP y otros protocolos, lo que lo hace más flexible en entornos empresariales en los que HTTP no siempre es el protocolo subyacente.

Los mensajes SOAP tienen una estructura rígida que especifica cómo debe procesarse el mensaje, lo que hace que SOAP sea más detallado que REST, pero también más estandarizado. Los estándares formales, la gestión de errores integrada y las rígidas especificaciones de seguridad de SOAP siguen siendo valiosas e impulsan su uso continuado en sectores como las finanzas y la sanidad.

La RPC es anterior a las APIs web y tiene implementaciones tanto heredadas como modernas. La RPC (a veces denominada llamada a subrutina o llamada a función) permite a una aplicación ejecutar una función o método en un servidor remoto como si fuera local. RPC se organiza en torno a acciones en lugar de recursos. En lugar de URIs individuales para cada recurso, las API de RPC suelen exponer un único endpoint y especificar la acción dentro de la carga útil de la solicitud.

XML-RPC, predecesor directo de JSON-RPC, utiliza XML para codificar sus llamadas y respuestas. Es más antiguo que SOAP pero más sencillo, lo que facilita su implementación, aunque la verbosidad de XML lo hace más pesado que las alternativas basadas en JSON. Es esencialmente un antepasado directo de JSON-RPC.

JSON-RPC funciona de la misma manera que XML-RPC, pero utiliza JSON en lugar de XML. JSON es más compacto y fácil de analizar que XML, lo que hace que JSON-RPC sea más ligero y legible que su predecesor.

gRPC es el nivel moderno y de alto rendimiento de la familia RPC. Lo desarrolló inicialmente Google y ahora se mantiene como un proyecto de código abierto. Mientras que las implementaciones de RPC más antiguas utilizan formatos basados en texto, gRPC utiliza Protocol Buffers (o Profobuf), un formato de serialización binaria que produce mensajes más pequeños y rápidos que JSON o XML.

También funciona sobre HTTP/2 en lugar de HTTP/1.1, añadiendo más beneficios de rendimiento. gRPC se utiliza comúnmente para la comunicación interna de microservicios y soporta transmisión bidireccional, lo que lo convierte en una opción sólida para flujos de datos en tiempo real.

GraphQL es un lenguaje de consulta de código abierto y un tiempo de ejecución del lado del servidor desarrollado por Facebook en 2012 para facilitar una obtención de recursos más eficiente. Está diseñado para eliminar la sobrerección (recibir más datos de los necesarios) y la subrección (requerir múltiples solicitudes para recibir los datos necesarios) permitiendo a los clientes especificar exactamente qué datos desean. GraphQL utiliza un único endpoint a través del cual los clientes pueden consultar varios recursos, con los resultados devueltos en una única respuesta.

Aunque es muy flexible, GraphQL es más complicado que REST y se utiliza sobre todo en entornos complejos en los que los requisitos de datos de los clientes varían significativamente.

Lee aquí una comparación más detallada entre REST y GraphQL.

Todas las API mencionadas siguen un modelo de solicitud/respuesta iniciado por el cliente. Vale la pena señalar dos excepciones importantes en un contexto de integración:

• Los WebSockets (APIs WebSocket) mantienen una conexión persistente y bidireccional, adecuada para casos de uso en tiempo real como fuentes de datos en vivo.
  
  
• Los Webhooks invierten el modelo por completo: en lugar de que el cliente inicie una solicitud, el servidor envía notificaciones push al cliente cuando se produce un evento especificado.

Las API públicas están totalmente expuestas a Internet y están disponibles para cualquier desarrollador u organización, generalmente sin restricciones o con restricciones mínimas. Puede que los desarrolladores tengan que obtener una clave de API, pero por lo demás, no se necesita mucho para trabajar con estas API. Están diseñadas para fomentar la integración externa y el desarrollo de terceros.

*No debe confundirse con la "Especificación OpenAPI (OAS)", sobre la que puede obtener más información aquí. 

Las API privadas no están disponibles para el público y solo son accesibles dentro de una organización definida. Suelen estar aislados en redes privadas y requieren una autenticación estricta para acceder. Las organizaciones suelen utilizar este tipo de APIs para conectar sistemas de software internos.

Desde el punto de vista del acceso, las API de partner se sitúan entre las API públicas y las privadas, ya que están disponibles para un grupo específico de business partners autorizados. Aunque se puede acceder a ellos a través de la Internet pública, no están disponibles para el público y solo se concede acceso a los usuarios autorizados. Las APIs de partner se utilizan para cosas como compartir datos B2B o monetizar flujos de datos, y su uso suele estar regulado por acuerdos específicos de los partners. 

*Las APIs compuestas a veces se incluyen en este desglose por tipo de acceso, pero se entienden mejor como un patrón arquitectónico que como un nivel de acceso. Las APIs compuestas combinan llamadas a APIs y pueden ser públicas, privadas o de socios. Se discuten más a fondo en la sección de APIs y microservicios.

El diseño de APIs es el proceso de toma de decisiones que determina cómo una API expone los datos y funcionalidades. En el proceso de diseño, los equipos deciden qué protocolos y estilos arquitectónicos utilizará la API, establecen convenciones coherentes para la nomenclatura, las estructuras de respuesta y la gestión de errores, deciden cómo se autenticará y autorizará el acceso, y definen una estrategia de control de versiones para gestionar los cambios de última hora. Estas y muchas otras decisiones determinan el funcionamiento de una API y la forma en que los desarrolladores interactúan con ella.

Básicamente, es un proceso que comienza con preguntas como: "¿Cómo se utilizará esta API?" y avanza para desarrollar un plan de diseño para las APIs que satisfaga las necesidades de la organización.

Las políticas de gobernanza de las APIs de una organización suelen influir en el diseño de las APIs. La gobernanza de las APIs se refiere al conjunto completo de estándares, políticas y prácticas que regulan cómo una Organización implementa y utiliza sus APIs. El diseño eficaz de APIs produce APIs que se adhieren a estas políticas predeterminadas.

La documentación de la API es como un manual de instrucciones técnicas que proporciona información sobre una API, como protocolos compatibles, idiomas y métodos de autenticación, fragmentos de código, definiciones estructurales y otra información necesaria para que los desarrolladores trabajen con una API. La documentación completa y actualizada de la API promueve una mejor experiencia de API para los desarrolladores e impulsa la adopción, integración y gestión exitosas de la API.

API-first (o API-design first) es un enfoque de desarrollo de software en el que las APIs se tratan como la base de una aplicación, diseñada antes de escribir cualquier código de aplicación. En lugar de empezar con la lógica empresarial backend y la estructura de la base de datos, las organizaciones definen primero el contrato (a menudo utilizando una especificación API como OpenAPI) y construyen el resto de la aplicación a su alrededor.

Es un enfoque preferido por las organizaciones con mucha integración, favorecido por su escalabilidad, fiabilidad y coherencia: la API es la fuente de la verdad, y todos los consumidores (aplicaciones web y aplicaciones móviles, dispositivos del Internet de las cosas (IoT), aplicaciones y modelos de IA, y otros sistemas) interactúan con la misma capa de API en lugar de integraciones a medida.

Algunas organizaciones tratan API-design first y API first como enfoques distintos, siendo este último una función más amplia que abarca a toda la organización y trata a las APIs como productos en sí mismas, con sus propios ciclos de vida, gestores de productos y hojas de ruta.

Microservicios es un estilo arquitectónico que divide una aplicación en servicios más pequeños e independientes. Estos servicios se comunican a través de APIs, a menudo una combinación de protocolos y estilos: por ejemplo, API REST para servicios externos, gRPC para comunicación interna entre servicios y webhooks para flujos basados en eventos. Una arquitectura de microservicios ofrece a los desarrolladores la flexibilidad de elegir el marco que mejor funcione para un servicio en particular.

También permite a los desarrolladores probar, implementar, actualizar, integrar, mantener y escalar servicios de forma independiente entre sí. El aislamiento de fallos se simplifica: un fallo de un solo componente no provoca que toda la aplicación se bloquee, y como los servicios están poco acoplados, la implementación interna puede cambiar con la ruptura de las integraciones.

Un problema común de los microservicios es lo que se conoce como el problema del "front end hablador". En una aplicación tradicional, los datos residen en una base de datos y un cliente puede consultar esta base de datos con una sola llamada. En los microservicios, los datos se distribuyen entre muchos servicios, lo que puede requerir que un cliente se comunique con docenas de servicios, a través de docenas de solicitudes separadas, para obtener los datos que necesita. Las APIs compuestas resuelven este problema presentando un endpoint unificado que actúa como capa de orquestación, atendiendo una solicitud del cliente, comunicándose con varios servicios de backend para recopilar los datos solicitados y devolviéndolos al cliente en una única carga útil.

Las APsI compuestas eliminan la necesidad de que los clientes realicen varias llamadas de ida y vuelta para una sola operación. También ocultan la complejidad interna del sistema: el cliente no necesita saber qué microservicio maneja qué datos, solo cómo llegar al endpoint compuesto. Y pueden reducir la latencia, ya que una sola llamada que se basa en la comunicación interna de microservicio suele ser más rápida que varias llamadas de ida y vuelta a través de una red externa.

A pesar de su beneficio, las arquitecturas de microservicio amplían la superficie de la API y añaden complejidad, destacando la importancia de una API management sólida.

API management es el proceso de publicar, proteger, controlar y monitorizar las APIs a lo largo de su ciclo de vida. Este trabajo suele centralizarse a través de una plataforma de gestión de APIs que ayuda a las organizaciones a aplicar políticas coherentes en todas sus APIs. Muchas de estas plataformas también incluyen herramientas de diseño y documentación, aunque esta sección se centra en el papel operativo de la gestión.

La gestión de la API Management incluye la supervisión de:

Una API Gateway es una capa de software que presenta un único punto de entrada para que los clientes accedan a múltiples servicios de backend. Evitan que los clientes tengan que comprender o interactuar con la complejidad de la arquitectura detrás de la puerta de enlace y se utilizan para controlar la proliferación de APIs creadas por microservicios.

Las funciones clave incluyen enrutamiento, autenticación, limitación de velocidad y monitorización. Los gateways también pueden gestionar la agregación de solicitudes, lo que los convierte en un lugar habitual para implementar APIs compuestas.

Seguridad API es un conjunto de prácticas y procedimientos que protegen las APIs y los datos que transmiten contra el uso indebido, los ataques de bots maliciosos y otras amenazas de ciberseguridad.  La seguridad API incluye la autenticación (verificar la identidad de un usuario), la autorización (determinar lo que puede hacer), el cifrado, la validación de entradas y mucho más. Las tecnologías de seguridad más comunes incluyen claves API y OpenID Connect (ODIC) para autenticación y OAuth para autorización. Una postura sólida de seguridad API ayuda a garantizar que solo los usuarios y aplicaciones autorizados accedan a las APIs. 

La limitación y la regulación de la velocidad controlan el volumen y el flujo de las solicitudes de API para ayudar a mantener los sistemas estables y disponibles. La limitación de velocidad restringe el número de llamadas que un cliente individual puede realizar en un periodo especificado, y la regulación gestiona el volumen de llamadas que un sistema acepta, generalmente ralentizando o poniendo en cola las solicitudes. Los límites de tarifas también cumplen una función comercial, ya que permiten a las organizaciones imponer niveles de uso para las APIs de pago.

Aunque son principalmente preocupaciones operativas, tanto la limitación como la regulación cumplen una función secundaria de seguridad, ayudando a frustrar los ataques de denegación de servicio y relleno de credenciales.

La API management aplica la estrategia de control de versiones establecida en el diseño. Las plataformas de gestión permiten a las organizaciones enrutar el tráfico a la versión de API correcta, ejecutar varias versiones simultáneamente y gestionar la obsolescencia de versiones anteriores. Esto permite a los equipos lanzar actualizaciones y nuevas versiones (incluso cambios importantes) y, a la vez, dar tiempo a las integraciones existentes para migrar sin interrupciones.

Las APIs son el tejido conectivo entre los sistemas empresariales, los servicios y los socios, y es vital comprender cómo funcionan. Una API que falla puede causar problemas con cada integración que dependa de ella. La monitorización y la observabilidad ayudan a los equipos a detectar y diagnosticar dichos problemas antes de que se propaguen en cascada por los sistemas conectados.

La monitorización de APIs rastrea el rendimiento, la disponibilidad, la funcionalidad y el uso de las APIs, proporcionando alertas cuando métricas como la latencia o las tasas de error superan umbrales predefinidos. La observabilidad se amplía a la monitorización, utilizando métricas, registros y rastreos para obtener una comprensión más profunda del estado del sistema y de la información superficial que la monitorización no marca.

Comprender el uso de las APIs ayuda a los equipos a planificar la capacidad, abordar las posibles amenazas y cumplir los requisitos gubernamentales y normativos.

Las APIs conectan aplicaciones de software, sistemas y flujos de trabajo para el intercambio de datos y servicios, una función a la que a menudo se denomina integración de API. En la mayoría de las integraciones modernas, las APIs son centrales para el movimiento de información entre servicios y sistemas.

Los casos de uso empresarial más comunes incluyen:

Las APIs permiten a los equipos integrar servicios de terceros en sus aplicaciones y flujos de trabajo. Por ejemplo, si una empresa de salsas picantes quiere incluir un mapa localizador de tiendas en su web mostrando a los minoristas asociados, puede usar la API de una aplicación de mapas para incrustar esa información en su sitio.

Las organizaciones utilizan las APIs para compartir datos y servicios con socios, proveedores y clientes. Una empresa de logística podría utilizar una API para exponer la información de seguimiento de pedidos para que los minoristas puedan incorporarla a sus propios sistemas.

Las organizaciones utilizan APIs para facilitar el intercambio de datos entre sistemas empresariales, como las plataformas de gestión de la relación con el cliente (CRM) y planificación de recursos empresariales (ERP). Si la dirección de un cliente se actualiza en una plataforma CRM, este cambio puede propagarse automáticamente a través de los sistemas conectados.

Las APIs se utilizan para acceder a herramientas de IA como grandes modelos de lenguaje (LLM) y modelos aprendizaje automático , así como para incorporarlas en aplicaciones y flujos de trabajo. La integración de modelos de IA funciona como otras integraciones de terceros: en lugar de que un equipo tenga que crear y entrenar un modelo complejo internamente, puede utilizar una API para acceder a un modelo externo.

Los agentes de IA también utilizan APIs para acceder a servicios y completar tareas, pero funcionan de forma diferente a las integraciones tradicionales en las que un desarrollador decide de antemano a qué API llamar y cómo llamarlas. Los agentes de IA toman esta decisión en tiempo de ejecución y deben tener libertad para analizar un problema, elegir una herramienta y explorar soluciones sobre la marcha. Necesitan una forma coherente de descubrir las herramientas y entender cómo usarlas.

Model Context Protocol (MCP), un estándar de código abierto introducido por Anthropic y ahora gobernado por la Fundación Linux, conecta modelos de IA y agentes con aplicaciones externas y sistemas, abordando esta brecha. Los servidores MCP suelen situarse sobre las APIs existentes como un "traductor universal", que describe las capacidades de una herramienta de una manera estandarizada que cualquier aplicación de IA compatible con MCP puede utilizar. En lugar de crear una integración personalizada entre cada aplicación de IA y cada herramienta, los desarrolladores pueden crear un servidor MCP para una herramienta en particular y ponerlo a disposición de cualquier agente compatible. El MCP se compara a menudo con un puerto USB-C para aplicaciones de IA, ya que proporciona un conector estándar en lugar de muchos personalizados.

Las aplicaciones móviles y web utilizan APIs para comunicarse con sus backends y recuperar datos o desencadenar acciones sin tener que acceder directamente a las bases de datos o a la lógica empresarial. Una organización puede crear la funcionalidad de backend una vez y utilizar las APIs para atender a clientes web, iOS y Android. Se pueden añadir nuevos canales sin tener que reconstruir el backend.

Algunas organizaciones van un paso más allá con un enfoque de Backend for Frontend que añade capas delgadas específicas de cliente además de las API compartidas y, al mismo tiempo, mantiene la lógica empresarial principal en un solo lugar.

Algunas aplicaciones no pueden esperar a que los clientes soliciten información. Las APIs en tiempo real y basadas en eventos cambian la relación, enviando información tan pronto como cambia o cuando ocurre un evento en particular, en lugar de esperar a que los clientes soliciten actualizaciones repetidamente.

Los webhooks notifican sobre eventos específicos a los sistemas conectados, mientras que WebSockets y la transmisión gRPC mantienen conexiones continuas para los flujos de datos en curso. Juntos, impulsan plataformas de trading financiero, sistemas de chat, juegos multijugador y el intercambio de datos de sensores IoT, manteniendo los sistemas actualizados sin necesidad de encuestas constantes.