As diferenças entre APIs e mensagens para comunicação de aplicações

Phil Wilkins | Evangelizador de Desenvolvimento na Nuvem, Oracle | Dezembro de 2022

Um software precisa conversar com outro software. Às vezes, o software em uma parte de uma aplicação precisa solicitar serviços ou trocar dados com outra parte da aplicação. Ou uma aplicação precisa solicitar serviços ou trocar dados com uma outra aplicação totalmente diferente.

Há dois mecanismos típicos usados para esses tipos de comunicação: interfaces de programação de aplicações (APIs) e sistemas de mensagens.

As diferenças entre APIs e mensagens às vezes podem se tornar confusas. Isso ocorre porque os termos são usados de várias maneiras ambíguas. A própria sigla API tem um significado explícito, mas por motivos que explicaremos a seguir, o termo assumiu vários significados diferentes. Mensagens é um termo geralmente usado de forma muito vaga para cobrir quase todas as comunicações de sistema para sistema. Então, vamos esclarecer o que realmente significa APIs e mensagens.

Uma definição detalhada de APIs

Em termos gerais, uma API é o contrato que define como esse software pode receber e responder às solicitações de serviço. Esse contrato é definido pelos desenvolvedores do software.

Parece simples? É, até certo ponto. Na prática, o significado implícito de API pode mudar com base no assunto da conversa. De acordo com o acrônimo, uma API é sobre a interface ou “contrato” pelo qual um software pode interagir com outro software. Às vezes, a conversa sobre uma API é focada em suas definições arquitetônicas de alto nível; às vezes é muito granular, detalhando as maneiras específicas pelas quais os desenvolvedores implementam a API.

Alguns livros e artigos sobre APIs usam a analogia de uma API sendo uma porta, com as características da API descrevendo essa porta. Por exemplo, pode ser a porta de um mercado que se abre automaticamente ou a porta ultrassegura de um cofre de banco. O contrato de uma aplicação - as características da porta - deve ajudar a abordar considerações como:

O que a API faz, em alto nível? Na nossa analogia com a porta, ela abre sem que o cliente precise parar e tocar em algo (porta de mercado) ou controla o acesso e protege o que está atrás da porta (cofre de banco)?
Quais cargas (dados sendo transmitidos) é necessário suportar para permitir que o software funcione? Por exemplo, o software pode receber um número de conta bancária e uma autorização de segurança e responder com o saldo dessa conta bancária.
Que dados devem ser trocados para executar esse serviço? Por exemplo, é importante definir exatamente como é um número de conta válido e uma autorização de segurança e definir o conteúdo da resposta. Os detalhes são importantes aqui; ambiguidade pode levar a erros.
Qual é o endereço da porta? Isso geralmente significa como o identificador de recurso universal (Universal Resource Identifier ou URI) para a solicitação é formado. Ou seja, como o solicitante realmente se comunica com a API?
Quais protocolos serão usados para se comunicar? Eles podem variar de tecnologias conhecidas, como HTTP e FTP, a protocolos especiais, como STOMP e QUIC.
A quais termos e condições o usuário da API deve aderir? Isso pode incluir detalhes de criptografia, um limite na frequência com que as APIs podem ser chamadas ou mecanismos de estorno para serviços comerciais.
Quais promessas a API faz? Isso pode incluir garantias de nível de serviço para a API, de modo que uma solicitação seja confirmada ou executada em um período de tempo específico.

Definindo mensagens no desenvolvimento de aplicações

Enquanto as APIs definem os termos de como o software enviará e receberá solicitações de serviço, o sistema de mensagens é o processo de envio de informações de um sistema para outro. A palavra-chave é processo.

Pense assim:

O envio de mensagens refere-se ao processo de transmissão de um pedaço de informação - a mensagem - do solicitante do serviço ao provedor de serviços (geralmente usando um terceiro conhecido como intermediário).

Para usar a analogia do mundo real, considere uma empresa enviando uma mensagem de texto para um cliente. O provedor de serviços precisa saber o número de telefone do destinatário para que a operadora de celular possa entregar a mensagem. A carga em si, no entanto, pode ser qualquer coisa do ponto de vista da operadora. A operadora não precisa saber se sua mensagem de texto está em inglês, espanhol, japonês ou é um emoji.
O envio de mensagens refere-se a toda a ação nos bastidores de levar essa mensagem do remetente ao cliente.

Você e seu cliente não precisam entender como funciona o processo de troca de mensagens; você está confiando que as operadoras e os fabricantes de smartphones fizeram seu trabalho corretamente. Da mesma forma, a operadora não precisa entender a carga útil; ela simplesmente precisa garantir que seja entregue à pessoa certa e o texto não seja ilegível ou distorcido.

Vale a pena reiterar que a maioria das plataformas de mensagens não se preocupa com a carga, desde que ela se encaixe nas restrições da tecnologia. Voltando à nossa analogia, os smartphones e as operadoras de celular não se importam se a sua mensagem é em inglês ou um emoji.

Veja mais detalhes sobre a composição de APIs, plataformas de API e gerenciamento de API.

APIs e mensagens trabalham juntas em sistemas corporativos

Os sistemas de software empresarial são construídos a partir de vários processos executáveis separados e, como resultado, requerem comunicação entre processos (IPC). As comunicações aqui podem ser complexas, exigindo muitas idas e vindas com muitas chamadas de API com muitos dados estritamente formatados para realizar uma transação. Essas transações devem ser cuidadosamente orquestradas e concluídas na ordem certa para atender a uma necessidade comercial.

Por exemplo, pense em um pedido de compra de um cliente. O processo precisará acessar o banco de dados do cliente; consultar o banco de dados do estoque, o sistema de contabilidade, um sistema de geração de faturas e o sistema de cobrança de cartão de crédito; ajustar o estoque e a conta do cliente; criar uma solicitação de depósito; e originar uma solicitação de remessa; tudo isso deve ser feito na ordem certa e preenchido corretamente.

Historicamente, essas interações eram feitas usando alguma forma de armazenamento compartilhado, como um sistema de arquivos ou um banco de dados. Porém, em sistemas corporativos mais modernos, os processos podem se comunicar diretamente entre si, agilizando o processo e eliminando problemas (como quando o estoque do seu pedido já foi alocado por pedidos anteriores).

Comportamento síncrono e assíncrono

Podemos caracterizar nossa comunicação como síncrona ou assíncrona por natureza. Comunicação síncrona significa que todas as partes envolvidas em uma comunicação devem estar presentes e aptas a reenviar. Em nosso exemplo de pedido, os sistemas envolvidos em pagamentos eletrônicos devem estar disponíveis para interação em tempo real. Em outros casos, a comunicação pode ser assíncrona, permitindo que as partes dos sistemas que desejam se comunicar não precisem estar presentes ao mesmo tempo. É assim que funciona quando mandamos emails. Para que uma comunicação funcione de forma assíncrona, precisamos que um intermediário esteja envolvido para permitir a passagem de informações de um lado para o outro.

Esses complexos sistemas de mensagens corporativas vêm em diferentes variedades ou padrões:

Barramento de serviço. O barramento de serviço atua como a cola entre diferentes processos e executa a orquestração entre esses processos, como na transação complexa mencionada acima. Os sistemas de barramento de serviço geralmente incorporam recursos de valor agregado, como a capacidade de traduzir cargas úteis de um formato para outro (inglês para francês em nossa analogia de mensagens de texto), rotear mensagens com base no conteúdo ou até mesmo tomar algumas decisões com base no estado da transação complexa. Por exemplo, as tarefas A e B podem ser executadas em paralelo; faça a tarefa C se a tarefa B for concluída com sucesso; se a tarefa B falhar, execute a tarefa D; se a tarefa D falhar, obtenha intervenção humana.

As mensagens de estilo barramento de serviço às vezes são descritas como usando um canal inteligente, devido a essa inteligência adicional em termos de roteamento e agendamento de mensagens no “canal” entre os provedores e os consumidores. Isso também é conhecido como orquestração.

O provedor chama o barramento de serviço que fornece uma mensagem. O barramento de serviço então pega a mensagem e a encaminha para os consumidores. Durante o roteamento, a mensagem pode estar sujeita a lógica transformacional e a filtragem.

Um termo sinônimo para barramento de serviço é barramento de mensagem. Quando essas tecnologias começaram a evoluir para se tornarem soluções de arquitetura orientada a serviços (SOA), havia algumas diferenças entre os barramentos de mensagens e os de serviço. Hoje, não há diferenças reais. Na verdade, o nome está diminuindo para apenas barramento.
Serviços da Web: No sentido mais amplo do termo, serviços da Web representam comunicações síncronas diretas entre dois processos, geralmente usando os protocolos TCP e HTTP (ou variações, como HTTPS e HTTP/2). O consumidor e o cliente são percebidos como conexões ponto a ponto (embora seja comum que o provedor suporte várias conexões simultâneas de clientes). Pode haver proxies (de firewalls de rede a gateways de API e caches da web) e intermediários de rede (switches e roteadores) entre os dois processos, mas nem o provedor nem o consumidor estarão cientes deles.
O provedor de mensagens se comunica diretamente com o consumidor. O processo de transmissão depende da disponibilidade de ambas as partes.
Message brokers:Message brokers são intermediários entre o provedor e o consumidor de mensagens e têm pontos em comum com barramentos de serviço e serviços da web.

Os brokers residem entre o remetente e os destinatários das mensagens e receberão a mensagem que está sendo comunicada e a armazenarão até que os destinatários a tenham consumido. Isso significa que a mensagem que está sendo transmitida pode ser feita sem se preocupar com a disponibilidade imediata do destinatário. Como resultado, esse tipo de comunicação costuma ser descrito como assíncrono ou “disparar e esquecer” porque você pode ter certeza de que a mensagem deve ser entregue em algum momento, desde que o intermediário permaneça operável.

A semelhança com os serviços web vem do fato de que a conexão entre o cliente e o broker é representada como uma conexão ponto a ponto; o message broker é funcionalmente invisível.

A semelhança com um barramento de serviço vem do fato de que o broker oferece um serviço de valor agregado, na medida em que pode reter as mensagens recebidas até que os destinatários estejam disponíveis. Ao contrário de um barramento de serviço mais robusto, um intermediário de mensagem tem inteligência mínima além de entender coisas simples, como saber quais destinos podem querer receber uma determinada mensagem e o que fazer se o destino não consumir a mensagem em tempo hábil.

Um estilo de comunicação intermediado é descrito como tendo um canal simples. Porque os brokers têm inteligência mínima e exigem que os terminais entendam o que é necessário quando uma mensagem precisa ser enviada ou recebida. Esse estilo é descrito como coreografia (em oposição à orquestração mais inteligente de um barramento de serviço).

O provedor de mensagens entrega sua mensagem ao broker. O broker então retém a mensagem até que os consumidores tenham solicitado uma mensagem ou seja capazes de recebê-la. O provedor não depende do consumidor.

O papel do streaming nas mensagens corporativas

Para essa discussão, o streaming pode ser visto como uma forma bastante especializada de envio de mensagens, embora algumas tecnologias de streaming possam suportar um elemento de processamento de dados. Streaming, nesse contexto, descreve o ato de enviar um fluxo contínuo de eventos por meio da tecnologia IPC para os mesmos destinos, independentemente de serviços da Web ou brokers de mensagens implementarem as comunicações. (Muito raramente os barramentos de serviço estão envolvidos, porque há muitos dados, fluindo muito rapidamente, para que a inteligência extra de um barramento de serviço seja necessária.)

Além do fluxo contínuo de dados, o streaming geralmente espera uma conectividade quase em tempo real ou de baixa latência. Isso não será uma surpresa quando você considera o fato de que serviços como o Netflix são tradicionalmente chamados de streaming de vídeo. Você certamente não deseja que o conteúdo de vídeo pare e comece enquanto novos bits são enviados do provedor ou enquanto um broker de mensagem transforma o vídeo de um formato para outro.

As tecnologias comuns para streaming de serviço da Web são WebSockets, fluxos gRPC e assinaturas GraphQL. Quando se trata de fluxos de mensagens intermediados (usando tecnologias, como Kafka), às vezes você pode aproveitar como o broker funciona para examinar uma “fatia” dos eventos transmitidos. Isso ajuda você a reunir insights valiosos, incluindo informações sobre o próprio fluxo, daí o termo análise de streaming.

Embora a lógica aplicada na análise de streaming possa ser sofisticada, o broker de mensagens não executa decisões ou manipulações de mensagens; é por isso que o broker ainda é considerado simples. Esses tipos de recursos de análise de streaming geralmente são implementados com tecnologias, como Kafka Streams.

Padrões da indústria de API e mensagens

APIs e sistemas de mensagens são simples de descrever, mas muito complexos em detalhes e características técnicas. Simplesmente não há espaço para ambiguidade, o que leva a uma necessidade real de padrões e documentação precisos da indústria e, idealmente, de melhor aplicação desses padrões.

Essa tem sido uma área em desenvolvimento, principalmente para APIs, há mais de dez anos. A indústria adotou a especificação OpenAPI para APIs baseadas em REST, que são uma forma de serviços da Web e provavelmente os tipos mais comuns de APIs usadas em software corporativo moderno.

Com APIs (e streaming), há vários padrões adicionais para definir e descrever aspectos das mensagens e sua transmissão. Isso inclui buffers de protocolo (também chamados de Protobuf e usados com gRPC) e, mais recentemente, GraphQL, JSON Schema e YAML.

No domínio de mensagens assíncronas, os últimos anos viram esforços bem-sucedidos para unir uma definição chamada AsyncAPI, que adaptou ideias do OpenAPI e outros padrões em desenvolvimento para atender aos muitos requisitos das mensagens.

Aplicações distribuídas modernas são implementadas como uma coleção de serviços que são partes separadas de software, às vezes rodando nos mesmos servidores, às vezes não. As APIs fornecem uma maneira para que esses softwares conversem entre si para solicitar serviços ou trocar informações. Os sistemas de mensagens fornecem a infraestrutura para facilitar as comunicações assíncronas e fornecem intermediários inteligentes para chamadas de API, que podem ser muito simples (a maneira como os textos dos smartphones funcionam) ou extremamente complexos (como a orquestração de transações comerciais complexas de várias etapas). Sem contar os serviços distribuídos se comunicando diretamente entre si por meio de APIs. Felizmente, técnicas e padrões em evolução permitem o uso de APIs em tudo, desde chamadas de banco de dados até streaming de mídia. E essas APIs e padrões de mensagens continuam a evoluir e avançar, tornando a transição para arquiteturas de software distribuídas modernas mais rápida, fácil e segura.