¿Qué es una API?

Una API o interfaz de programación de aplicaciones es un conjunto de definiciones y protocolos que se usa para diseñar e integrar el software de las aplicaciones.

Las API permiten que tus productos y servicios se comuniquen con otros, sin necesidad de saber cómo están implementados. Esto simplifica el desarrollo de las aplicaciones y permite ahorrar tiempo y dinero. Al momento de diseñar herramientas y productos nuevos (o de gestionar los actuales), las API brindan flexibilidad; simplifican el diseño, la administración y el uso de las aplicaciones; y ofrecen oportunidades de innovación.

En ocasiones, las API pueden considerarse contratos, con documentación que representa un acuerdo entre las partes: si la parte 1 envía una solicitud remota estructurada de una manera específica, el software de la parte 2 responderá de esa manera.

Las API también permiten la colaboración entre el equipo de negocios y el de TI, ya que simplifican la forma en que los desarrolladores integran los elementos de las aplicaciones nuevas en una arquitectura actual. Las necesidades empresariales suelen cambiar rápidamente en respuesta a los mercados digitales en constante evolución, donde los nuevos competidores pueden transformar por completo un sector con una nueva aplicación. Para seguir siendo competitivas, las empresas deben respaldar el desarrollo y la implementación rápidos de servicios innovadores. El desarrollo de aplicaciones de nube es una forma clara de agilizar el proceso de desarrollo, y consiste en conectar una arquitectura de aplicaciones de microservicios a través de las API.

Las API son un medio simplificado para conectar tu propia infraestructura a través del desarrollo de aplicaciones en la nube, pero también te permiten compartir tus datos con clientes y otros usuarios externos. Las API públicas aportan un valor empresarial único porque simplifican y amplían tus conexiones con los partners y, además, pueden rentabilizar tus datos (un ejemplo conocido es la API de Google Maps).

Por ejemplo, imagínate una empresa distribuidora de libros. Podría ofrecer a los clientes una aplicación en la nube que le permitiera al personal de la librería verificar la disponibilidad de los libros con el distribuidor. El desarrollo de la aplicación podría ser costoso, verse limitado por la plataforma, llevar mucho tiempo y requerir mantenimiento permanente.

Otra opción es que la distribuidora de libros proporcionara una API para verificar la disponibilidad en inventario. Este enfoque presenta varios beneficios:

• Permite que los clientes accedan a los datos con una API que les ayude a añadir información sobre su inventario en un solo lugar.
• La distribuidora de libros podría realizar cambios en sus sistemas internos sin afectar a los clientes, siempre y cuando el comportamiento de la API fuera el mismo.
• Con una API disponible de forma pública, los desarrolladores que trabajan para la distribuidora de libros, los vendedores o los terceros podrían desarrollar una aplicación para ayudar a los clientes a encontrar los libros que necesiten. Esto podría dar como resultado mayores ventas u otras oportunidades de negocio.

En resumen, las API te permiten habilitar el acceso a tus recursos y, al mismo tiempo, mantener la seguridad y el control. La manera en que permites el acceso y a quién se lo otorgas es tu decisión. La seguridad de las API depende de su correcta gestión, lo que incluye el uso de una puerta de enlace de API. Para conectarte a las API y crear aplicaciones que utilicen los datos o las funciones que ofrecen, se puede usar una plataforma de integración distribuida que conecte todos los elementos, incluidos los sistemas heredados y el Internet de las cosas (IoT).

El acceso de los partners o el público a tus API permite:

• Crear nuevos canales de ingresos o ampliar los existentes.
• Expandir el alcance de su marca.
• Facilitar la innovación abierta o lograr mayor eficiencia, gracias al desarrollo y la colaboración externos.

Suena maravilloso, ¿no? ¿Pero cómo lo logran las API?

Volvamos al ejemplo de la empresa distribuidora de libros.

Supongamos que uno de los partners de la empresa desarrolla una aplicación que ayuda a las personas a encontrar libros en los estantes de cierta librería. Esta experiencia mejorada atrae más compradores a la librería (que es cliente de la distribuidora) y expande un canal de ingresos existente.

Es posible que un tercero utilice una API pública para desarrollar una aplicación que permita a las personas comprar libros directamente del distribuidor, en lugar de hacerlo en una tienda. Esto abre un nuevo canal de ingresos para la distribuidora de libros.

Las API compartidas, ya sea con los partners elegidos o con todo el mundo, tienen efectos positivos. Mientras más se asocie con otros gracias a las API, mayor difusión obtendrá su marca, independientemente de los esfuerzos publicitarios de la empresa. Si usted utiliza una API pública, por ejemplo, para dar acceso a la tecnología a todo el mundo, alienta a los desarrolladores a crear un ecosistema de aplicaciones en torno a su API. Mientras más personas usen tu tecnología, más personas estarán dispuestas a hacer negocios contigo.

Hacer pública la tecnología puede generar resultados novedosos e inesperados. Estos resultados, a veces, alteran sectores completos. En el caso de nuestra distribuidora de libros, las nuevas empresas (un servicio de préstamo de libros, por ejemplo) pueden cambiar la manera en que comercializa sus servicios. Los partners y las API públicas te permiten aprovechar los esfuerzos creativos de una comunidad más grande que tu equipo de desarrolladores internos. Las nuevas ideas surgen de todas partes, y las empresas deben ser conscientes de los cambios en su mercado y estar listas para actuar en consecuencia. Las API son de gran ayuda.

Las API surgieron en los comienzos de la informática, mucho antes que la computadora personal. En esa época, una API normalmente se usaba como biblioteca para los sistemas operativos. Casi siempre estaban habilitadas localmente en los sistemas en los que operaban, aunque a veces pasaban mensajes entre las computadoras centrales. Después de casi 30 años, las API se expandieron más allá de los entornos locales. A principios del año 2000, ya eran una tecnología importante para la integración remota de datos.

Las API remotas están diseñadas para interactuar en una red de comunicaciones. Por "remoto" nos referimos a que los recursos que administran las API están fuera de la computadora que solicita alguno de dichos recursos. Dado que la red de comunicaciones más usada es Internet, la mayoría de las API están diseñadas de acuerdo con los estándares web. No todas las API remotas son API web, pero se puede suponer que las API web son remotas.

Las API web normalmente usan HTTP para solicitar mensajes y proporcionar una definición de la estructura de los mensajes de respuesta. Por lo general estos mensajes de respuesta toman la forma de un archivo XML o JSON. Estos son los formatos preferidos porque presentan los datos de una manera fácil de manejar para otras aplicaciones.

Con la expansión de las API web, se desarrolló una especificación de protocolo para estandarizar el intercambio de información: Simple Object Access Protocol, más conocido como SOAP. Las API diseñadas con SOAP usan XML para el formato de sus mensajes y reciben solicitudes a través de HTTP o SMTP. Con SOAP, es más fácil que las aplicaciones que funcionan en entornos distintos o están escritas en diferentes lenguajes compartan información.

Otra especificación es la Transferencia de Estado Representacional (REST). Las API web que se ajustan a las limitaciones de la arquitectura REST se denominan API RESTful. La diferencia entre REST y SOAP radica en un aspecto fundamental: la primera es un estilo de arquitectura, mientras que la segunda es un protocolo. Esto significa que no hay ningún estándar oficial para las API web de RESTful. Tal como se define en la tesis de Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures", las API son RESTful siempre que cumplan con las seis limitaciones principales de un sistema de RESTful.

• Arquitectura cliente-servidor: La arquitectura de REST incluye clientes, servidores y recursos, y gestiona las solicitudes a través de HTTP.
• Sin estado: El contenido de los clientes no se almacena en el servidor entre las solicitudes. En su lugar, la información sobre el estado de la sesión está en el cliente.
• Capacidad de caché: Con el almacenamiento en caché, no son necesarias algunas interacciones cliente-servidor.
• Sistema en capas: Las interacciones cliente-servidor pueden estar mediadas por capas adicionales. Estas capas pueden ofrecer funcionalidades adicionales, como equilibrio de carga, cachés compartidos o seguridad.
• Código por solicitud (opcional): Los servidores pueden ampliar las funciones de un cliente transfiriendo código ejecutable.
• Interfaz uniforme: Esta limitación es fundamental para el diseño de las API RESTful e incluye cuatro aspectos.
  • Identificación de los recursos en las solicitudes: Los recursos se identifican en las solicitudes y se separan de las representaciones que se devuelven al cliente.
  • Manipulación de los recursos a través de representaciones: Los clientes reciben archivos que representan recursos. Estas representaciones deben tener la información suficiente como para poder ser modificadas o eliminadas.
  • Mensajes autodescriptivos: Cada mensaje que se devuelve a un cliente contiene suficiente información para describir cómo debe procesar la información.
  • Hipermedia como motor del estado de la aplicación: Después de acceder a un recurso, el cliente REST debe poder detectar mediante hipervínculos todas las otras acciones que están disponibles actualmente.

Estas limitaciones pueden parecer demasiadas, pero son mucho más sencillas que un protocolo definido previamente. Por eso, las API de RESTful son cada vez más frecuentes que las de SOAP.

En los últimos años, la especificación de OpenAPI se ha convertido en un estándar común para definir las API de REST. OpenAPI establece una manera para que los desarrolladores diseñen las API de REST sin depender de un lenguaje, de forma tal que los usuarios puedan comprenderlas con el mínimo esfuerzo.

Otro estándar de API que ha surgido es GraphQL, un lenguaje de consulta y un tiempo de ejecución del servidor que es una alternativa a REST. GraphQL prioriza brindar a los clientes exactamente los datos que solicitan y nada más. Como alternativa a REST, GraphQL permite que los desarrolladores creen consultas para extraer datos de varias fuentes en una sola llamada a la API.

Obtén más información sobre las diferencias entre SOAP y REST

Los dos enfoques de arquitectura en los que más se utilizan las API remotas son la arquitectura orientada a los servicios (SOA) y la arquitectura de microservicios. La SOA es el más antiguo de los dos, y comenzó como una mejora de las aplicaciones monolíticas. En lugar de usar una sola aplicación que haga todo, se pueden usar varias aplicaciones que proporcionen diferentes funciones y que no tengan conexión directa, todo gracias a un patrón de integración, como un bus de servicios empresariales (ESB).

Aunque en muchos aspectos la SOA es más sencilla que una arquitectura monolítica, conlleva un riesgo de cambios en cascada en todo el entorno si las interacciones de los componentes no se comprenden claramente. Esta complejidad adicional vuelve a presentar algunos de los problemas que la SOA pretendía solucionar.

Las arquitecturas de microservicios se parecen a los patrones SOA en que los servicios son especializados y no tienen conexión directa. Pero además, descomponen las arquitecturas tradicionales en partes más pequeñas. Los servicios de la arquitectura de microservicios usan un marco de mensajería común, como las API de RESTful. Utilizan API de RESTful para comunicarse entre sí, sin necesidad de operaciones complejas de conversión de datos ni capas de integración adicionales. Usar las API de RESTful permite e incluso fomenta una distribución más rápida de nuevas funciones y actualizaciones. Cada servicio es independiente. Un servicio se puede reemplazar, mejorar o abandonar, sin afectar los demás servicios de la arquitectura. Esta arquitectura ligera optimiza los recursos distribuidos o en la nube y admite la adaptación dinámica de los servicios individuales.

Obtén más información sobre las SOA

Un webhook es una función de devolución de llamadas que se basa en el protocolo HTTP para que dos API se comuniquen mediante eventos de forma ligera. Muchas aplicaciones web los utilizan para recibir pequeñas cantidades de datos de otras aplicaciones, pero también sirven para activar flujos de trabajo de automatización en los entornos de GitOps.

Los webhooks también se conocen como API inversas o API push porque, al usarlos, quien debe encargarse de la comunicación es el servidor, en vez del cliente. Es decir, el servidor le envía al cliente una solicitud POST única de HTTP cuando los datos están disponibles, en lugar de que el cliente le envíe solicitudes de HTTP hasta obtener una respuesta. A pesar de las denominaciones que se utilizan para los webhooks, no son API, sino que ambos funcionan en conjunto. Las aplicaciones deben tener una API para usar un webhook. 

Obtén más información sobre los webhooks

El protocolo de contexto de modelos (MCP) y las API actúan como puentes digitales que conectan sistemas separados. Las funciones de MCP se basan en las API, y las primeras no existirían si no fuera por las segundas. 

Las tecnologías difieren en la forma en su funcionamiento y propósito:

• El MCP conecta los modelos de lenguaje con herramientas y datos externos, lo que respalda los flujos de trabajo que se adaptan e improvisan en tiempo real. 
• Los flujos de trabajo de las API tradicionales siguen un conjunto establecido de reglas. Una vez que se conectan dos sistemas, las interacciones se limitan a un conjunto específico de acciones programadas por un desarrollador.

Obtén más información sobre el MCP y las API