Las diferencias entre las API y la mensajería para la comunicación de aplicaciones

Phil Wilkins | Cloud Developer Evangelist, Oracle | diciembre de 2022

El software debe comunicarse con otro software. Unas veces, el software de una parte de una aplicación necesita solicitar servicios o intercambiar datos con otra parte de la misma aplicación. Otras veces, una aplicación tiene que solicitar servicios o intercambiar datos con una aplicación completamente diferente.

Existen dos mecanismos que se utilizan típicamente en estos tipos de comunicación: interfaces de programación de aplicaciones (API) y la mensajería.

Las diferencias entre las API y los mensajes a veces pueden resultar confusas. Esto se debe a que los términos se utilizan de muchas maneras ambiguas. El acrónimo API sí tiene un significado explícito, pero por razones que explicaremos a continuación, el término se ha utilizado con varios significados diferentes. La mensajería es un término que a menudo se utiliza muy libremente para referirse a casi cualquier comunicación entre sistemas. Por lo tanto, aclaremos lo que realmente se entiende por API y mensajería.

Definición detallada de API

En términos generales, una API es el contrato que define cómo ese software puede recibir y responder a las solicitudes de servicio. Ese contrato lo establecen los desarrolladores del software.

¿Te parece sencillo? Desde un punto de vista sí lo es. En la práctica, el significado implícito de la API puede cambiar en función del tema de conversación. Si analizamos el acrónimo, una API es una interfaz, o "contrato", mediante la cual una parte del software puede interactuar con otra parte del mismo software. La conversación sobre una API a veces se centra en sus definiciones de arquitectura de alto nivel. En ocasiones, es muy granular y detalla las formas específicas en que los desarrolladores implantan la API.

Algunos libros y artículos que abordan el tema comparan la API con una puerta, y las características de la API describen cómo es esa puerta. Por ejemplo, podría ser una puerta de tienda de comestibles que se abre automáticamente o una puerta blindada de una cámara de seguridad de un banco. El contrato de una aplicación, esto es, las características de la puerta, debe ayudar a abordar aspectos como:

¿Qué hace la API a rasgos generales? En nuestra analogía de puerta, ¿se abre sin necesidad de que el visitante se detenga y toque algo (puerta de tienda de comestibles) o controla el acceso y protege lo que está detrás de la puerta (cámara de seguridad de un banco)?
¿Qué cargas útiles (datos que se transmiten) serán necesarias para permitir que el software funcione? Por ejemplo, el software puede recibir un número de cuenta bancaria y una autorización de seguridad y responder con el saldo de esa cuenta bancaria.
¿Qué datos se deben intercambiar para realizar ese servicio? Por ejemplo, es importante definir exactamente la naturaleza del número de cuenta y la autorización de seguridad válidos y definir el contenido de la respuesta. Aquí los detalles son fundamentales. La ambigüedad puede provocar errores.
¿Cuál es la dirección de la puerta? Esto generalmente significa cómo se forma el identificador de recursos universal (URI) para la solicitud. Es decir, ¿cómo habla realmente el solicitante con la API?
¿Qué protocolos se utilizarán para comunicarse? Pueden abarcar desde tecnologías conocidas, como HTTP y FTP, hasta protocolos especiales, como STOMP y QUIC.
¿A qué términos y condiciones debe adherirse el usuario de la API? Estos pueden incluir detalles de cifrado, un límite en la frecuencia con la que se pueden llamar a las API o mecanismos de cargo al usuario para los servicios comerciales.
¿Qué promesas realiza la API? Pueden incluir garantías de nivel de servicio para la API, de modo que una solicitud se reconocerá o realizará dentro de un periodo de tiempo específico.

Definición de la mensajería en el desarrollo de aplicaciones

Mientras las API definen en qué condiciones el software enviará y recibirá solicitudes de servicio, los mensajes son el proceso que se centra en enviar información de un sistema a otro. La palabra clave aquí es "proceso".

Míralo de esta manera:

La mensajería se refiere al proceso de transmisión de parte de información (el mensaje) desde el solicitante del servicio al proveedor del servicio (a menudo utilizando un tercero conocido como intermediario).

Para utilizar una analogía del mundo real, imaginemos una empresa que envía un mensaje de texto a un cliente. El proveedor de servicios debe conocer el número de teléfono del destinatario para que el operador móvil pueda entregar el mensaje. Sin embargo, la carga útil en sí puede ser cualquier cosa desde la perspectiva del transportista. El operador no necesita saber si su mensaje de texto está en inglés, español, japonés o es un emoji.
La mensajería hace referencia a toda la acción en segundo plano de llevar ese mensaje del remitente al cliente.

No necesitas, ni tú ni tu cliente, entender cómo funciona el proceso de mensajería, ya que confías en que los transportistas y los fabricantes de teléfonos inteligentes hayan hecho su trabajo correctamente. Asimismo, el transportista no necesita entender la carga útil. Solo debe asegurarse de que se entregue a la persona adecuada y no se daña ni altera.

Vale la pena reiterar que la mayoría de las plataformas de mensajería no se preocupan por la carga útil siempre que esta se ajuste a las restricciones de la tecnología. Para retomar nuestra analogía, a los operadores de móviles y teléfonos inteligentes no debe preocuparles si tu mensaje está en inglés o es un emoji.

Obtén más información sobre la composición de las API, las plataformas de API y la gestión de API.

Las API y la mensajería se utilizan conjuntamente en los sistemas empresariales

Los sistemas de software empresarial se crean a partir de varios procesos ejecutables independientes y, en consecuencia, requieren comunicación entre procesos (IPC). Para llevar a cabo una transacción, las comunicaciones aquí pueden ser complejas, lo que requiere muchas idas y venidas, con muchas llamadas a la API con múltiples datos estrictamente formateados. Esas transacciones se deben organizar y completar cuidadosamente en el orden adecuado para satisfacer una necesidad de negocio.

Por ejemplo, piensa en una orden de compra de cliente. El proceso necesitará acceder a la base de datos de clientes; consultar la base de datos de inventario, el sistema contable, un sistema de generación de facturas de venta y el sistema de cargos con tarjeta de crédito; ajustar el inventario y la cuenta de cliente; crear una solicitud de almacén, y originar una solicitud de envío. Todo debe realizarse en el orden correcto y completarse de manera adecuada.

Históricamente, estas interacciones se realizaron mediante algún tipo de almacenamiento compartido, como un sistema de archivos o una base de datos. Sin embargo, en sistemas empresariales más modernos, los procesos pueden comunicarse directamente entre sí, acelerando el proceso y eliminando problemas (por ejemplo, cuando el inventario de su pedido ya ha sido asignado en pedidos previos).

Comportamiento síncrono y asíncrono

Podemos caracterizar nuestra comunicación como de naturaleza síncrona o asíncrona. La comunicación síncrona significa que todas las partes implicadas en una comunicación deben estar presentes y ser capaces de reenviar información. En nuestro ejemplo de pedido, los sistemas involucrados en pagos electrónicos deben estar disponibles para realizar la interacción en tiempo real. En otros casos, la comunicación puede ser asíncrona, lo cual permite que las partes de los sistemas que deseen comunicarse no tengan que estar presentes en el mismo momento. Así es como funciona cuando intercambiamos correos electrónicos entre las distintas partes. Para que una comunicación funcione de forma asíncrona, necesitamos que un intermediario participe para permitir la transferencia de información de una parte a otra.

Estos complejos sistemas de mensajería empresarial responden a diferentes variedades o patrones:

Bus de servicio empresarial. El bus de servicio actúa como enlace entre diferentes procesos y se encarga de organizar todos estos procesos, como en la transacción compleja mencionada anteriormente. Los sistemas de bus de servicio suelen incorporar funciones de valor añadido, como la capacidad de traducir cargas útiles de un formato a otro (del inglés al francés en nuestra analogía de mensajes de texto), dirigir mensajes en función del contenido del mensaje o incluso tomar algunas decisiones en función del estado de la transacción compleja. Por ejemplo, las tareas A y B se pueden realizar en paralelo y realizar la tarea C si la tarea B se completa correctamente. Si las tareas B fallan, podrás realizar la tarea D y si la tarea D falla, puedes recurrir a la intervención humana.

Los mensajes del tipo bus de servicio se describen a veces como el uso de una canalización inteligente, debido a esa inteligencia agregada en términos de enrutamiento y programación de mensajes en el "canal" entre proveedores y consumidores. También se le conoce como organización.

El proveedor de mensajes llama al bus de servicio que proporciona el mensaje. El bus de servicio toma el mensaje y lo dirige a los consumidores. Durante el enrutamiento, el mensaje puede estar sujeto a una lógica transformacional y a un proceso de filtrado.

Un sinónimo para bus de servicio es bus o flujo de mensajes. Cuando estas tecnologías evolucionaron por primera vez para convertirse en soluciones de arquitectura orientada a servicios (SOA, por sus siglas en inglés), existían algunas diferencias entre los buses de mensajes y los buses de servicio. En la actualidad, podemos afirmar que no hay diferencias reales. De hecho, el nombre cada vez más se utiliza sencillamente en su forma abreviada bus.
Servicios web: en el sentido más amplio del término, los servicios web representan comunicaciones síncronas directas entre dos procesos, normalmente mediante los protocolos TCP y HTTP (o variaciones, como HTTPS y HTTP/2). El consumidor y el cliente se realizan como conexiones punto a punto (aunque es común que el proveedor acabe por admitir múltiples conexiones de cliente a la vez). Entre los dos procesos puede haber proxies (desde firewalls de red hasta gateways de API y cachés web) y dispositivos de red intermediarios (conmutadores y enrutadores) , pero ni el proveedor ni el consumidor los conocerán.
El proveedor de mensajes se comunica directamente con el consumidor. El proceso de transmisión depende de que ambas partes estén disponibles.
Brókers de mensajería: los brókers de mensajería son intermediarios entre el proveedor y el consumidor de mensajes, y comparten características tanto con los buses de servicio como con los servicios web.

Los brókers se encuentran entre el remitente y los receptores de los mensajes y recibirán el mensaje que se comunica y lo almacenarán hasta que los destinatarios lo hayan consumido. Esto significa que el mensaje que se transmite se puede hacer sin preocuparse por la disponibilidad inmediata del destinatario. En consecuencia, este tipo de comunicación se describe a menudo como asíncrona o "disparar y olvidarse" porque sabes que el mensaje se va a entregar en algún momento, siempre que el bróker siga funcionando.

La similitud con los servicios web proviene del hecho de que la conexión entre el cliente y el bróker se representa como una conexión punto a punto; el bróker de mensajería es funcionalmente invisible.

El parecido a un bus de servicio se debe al hecho de que el bróker ofrece un servicio de valor añadido, ya que puede mantener los mensajes recibidos hasta que los destinatarios estén disponibles. A diferencia de un bus de servicio más sólido, un bróker de mensajería tiene una inteligencia mínima aparte de entender cosas sencillas, como saber qué destinos potenciales podrían querer recibir un mensaje concreto y qué hacer si el destino no consume el mensaje en el momento oportuno.

Un estilo de comunicación con bróker se caracteriza por tener un dumb pipe. Debido a que los brókers tienen una inteligencia mínima, es preciso que los puntos finales entiendan lo que se necesita cuando un mensaje debe ser enviado o recibido. Este estilo se describe como coreografía (en contraposición a la organización más inteligente de un bus de servicio).

El proveedor de mensajes envía su mensaje al bróker. A continuación, este mantiene el mensaje hasta que los consumidores lo soliciten o puedan recibirlo. El proveedor no depende del consumidor.

El papel del streaming en los mensajes empresariales

Para el tema que estamos tratando, el streaming puede concebirse como una forma de mensajería bastante especializada, aunque algunas tecnologías de streaming puedan admitir elementos del procesamiento de datos. El streaming, en este contexto, describe el acto de enviar un flujo continuo de eventos a través de la tecnología IPC a los mismos destinos, independientemente de que los servicios web o los brókers de mensajería implementen o no las comunicaciones. (Muy rara vez entra en juego un bus de servicio, ya que el volumen de datos es demasiado elevado y estos fluyen demasiado rápido como para que sea necesaria su inteligencia adicional).

Además del flujo continuo de datos en un canal, el streaming generalmente necesita una conectividad casi en tiempo real o de baja latencia. Esto no debería sorprenderte si consideras el hecho de que servicios como Netflix se denominan tradicionalmente streaming de video. Seguro que no quieres que el contenido de video se detenga y se vuelva a iniciar mientras el proveedor envía nuevas partes del video o mientras un bróker de mensajería transforma el video de un formato a otro.

Las tecnologías más habituales de streaming de servicios web son WebSockets, transmisiones gRPC y suscripciones GraphQL. Cuando se trata de flujos de mensajería con bróker (mediante tecnologías como Kafka), a veces puedes aprovechar el modo en que trabaja el bróker para ver un "fragmento" de los eventos transmitidos. De esta forma, podrás recopilar información valiosa, incluida información sobre el propio modo de transmisión, de ahí el término análisis de streaming.

Aunque la lógica aplicada en el análisis de streaming puede resultar sofisticada, el bróker de mensajería no realiza la toma de decisiones ni manipula los mensajes. Es por ese motivo, que el bróker sigue siendo considerado un elemento no inteligente. Este tipo de capacidades de análisis de streaming se suele implantar con tecnologías como Kafka Streams.

Estándares del sector para API y mensajería

Las API y los sistemas de mensajería son fáciles de describir, pero muy complejos en cuanto a sus detalles y características técnicas. Simplemente no hay espacio para la ambigüedad, lo cual genera la necesidad real de incorporar estándares y documentación precisos de la industria y, si es posible, la mejor aplicación de estos estándares.

Este ha sido un ámbito de desarrollo durante más de diez años, especialmente para las API. El sector ha adoptado la especificación OpenAPI para las API basadas en REST, que son una forma de servicios web, y probablemente los tipos más comunes de API utilizadas en el software empresarial moderno.

Con las API (y el streaming) hay una serie de estándares adicionales para definir y describir aspectos de los mensajes y su transmisión. Estos incluyen búferes de protocolo (también denominados Protobuf y utilizados con gRPC) y, más recientemente, GraphQL, JSON Schema y YAML.

En el ámbito de la mensajería asíncrona, en los últimos años se han realizado esfuerzos de gran éxito para fusionar una definición denominada AsyncAPI, que ha adaptado ideas de OpenAPI y otros estándares en evolución para abordar las múltiples exigencias de la mensajería.

Las aplicaciones distribuidas modernas se implementan como una recopilación de servicios que son partes independientes de software, que a veces se ejecutan en los mismos servidores y otras veces no. Las API proporcionan una fórmula para que esas partes del software se comuniquen entre sí para solicitar servicios o intercambiar información. Los sistemas de mensajería proporcionan la infraestructura necesaria para facilitar las comunicaciones asíncronas y proporcionar intermediarios inteligentes para llamadas de API, que pueden ser muy simples (la forma en que funcionan los textos de los smartphones) o extremadamente complejas (como la organización para transacciones empresariales complejas multifase). Sin mencionar los servicios distribuidos que se comunican directamente entre sí mediante API. Afortunadamente, las técnicas y estándares en evolución permiten el uso de API en todo, desde llamadas de base de datos hasta medios de streaming. Además, esas API y los estándares de mensajería siguen evolucionando y avanzando, lo que hace que la transición a arquitecturas de software distribuidas modernas sea más rápida, fácil y segura.