O que é uma API (interface de programação de aplicativos)?

As APIs expõem apenas os dados e as funcionalidades necessários para uma interação específica, mantendo ocultos outros detalhes de implementação internos. Essa abstração protege a integridade do sistema e simplifica a forma como os componentes de software se comunicam.

Existem muitos tipos de APIs, APIs de hardware e firmware, APIs de sistemas operacionais, APIs de bibliotecas e frameworks, APIs da web e outras, e em alto nível, todas elas operam da mesma forma: definem um contrato entre dois softwares, especificando o que pode ser solicitado e retornado.

Como uma explicação centrada na integração, este artigo foca predominantemente em APIs da web (um tipo de API que permite que softwares façam solicitações por uma rede, muitas vezes usando HTTP), como elas funcionam, suas diferenças e como são usadas para conectar sistemas, sincronizar dados e automatizar fluxos de trabalho.

É útil pensar na comunicação de APIs em termos de solicitação e resposta entre um cliente e um servidor. A aplicação que envia a solicitação é o cliente, e o servidor fornece a resposta. A API define os termos de comunicação entre eles.

Para um exemplo simples, considere o processamento de pagamentos de terceiros. Quando um usuário compra um produto em um site de e-commerce, o site pode oferecer a opção de “Pagar com PayPal”. Essa função depende de APIs para essa conexão.

• Quando o comprador clica no botão de pagamento, uma chamada de API é iniciada. Essa solicitação é processada de uma aplicação para o servidor da web por meio do Uniform Resource Identifier (URI) da API e inclui um verbo de solicitação, cabeçalhos e, às vezes, um corpo de solicitação. Juntos, esses elementos especificam o que está sendo solicitado e como.
  
  
• Depois de receber uma solicitação válida do cliente, a API encaminha a solicitação para o programa externo ou servidor da web, neste caso, o sistema de pagamento de terceiros, e retorna uma resposta com as informações solicitadas.
  
  
• A API transfere os dados para o aplicativo que fez a solicitação inicial, neste caso, o site do produto.

Para o usuário final, toda essa troca é invisível — ele simplesmente vê uma confirmação de pagamento bem-sucedido.

As APIs existem em todas as camadas do software, desde as próximas ao hardware até os serviços da web com os quais a maioria das pessoas interage diariamente. Em muitas conversas diárias, a API é usada como sinônimo de API da web. Mas existem muitos tipos de APIs que atendem a diferentes casos de uso, incluindo:

• As APIs de hardware e firmware permitem que o software se comunique com os componentes físicos de um dispositivo, como processadores e sensores.
  
  
• As APIs do sistema operacional permitem que o software se comunique com os sistemas operacionais para serviços como gerenciamento de arquivos, processos e memória.
  
  
• As APIs de bibliotecas e frameworks expõem código pré-escrito (funções, métodos e hooks) com o qual os desenvolvedores interagem diretamente em suas aplicações, sem passar por uma rede. 
  
  
• As APIs de bancos de dados permitem que o software se comunique, manipule e extraia informações armazenadas em um banco de dados.
• As APIs da web permitem que o software faça solicitações em uma rede, muitas vezes usando HTTP. Elas são um tipo de APIs remotas, facilitando a comunicação e a manipulação de recursos entre diferentes máquinas, em vez de um único dispositivo.

*Vale lembrar que alguns sistemas mais antigos expõem protocolos de rede (como FTP, SMTP e SSH) diretamente como sua interface de integração. Tecnicamente, eles se encaixam em uma definição ampla de APIs, embora sejam categorizados pela forma como se comunicam, não por com o que interagem, e são menos relevantes para uma discussão focada em integração.

As APIs da web são as mais comuns para integração. Ao contrário dos outros tipos de APIs listados acima, elas são projetadas para comunicação entre aplicações separadas em uma rede.

REST é o estilo arquitetônico dominante para APIs da web atualmente. As APIs REST, também conhecidas como APIs RESTful, dependem de seis restrições arquitetônicas orientativas definidas pela primeira vez por Roy Fielding para a criação de serviços da web escaláveis, flexíveis e desacoplados.

O REST disponibiliza dados como recursos, e as APIs REST usam métodos HTTP como GET, POST, PUT, PATCH e DELETE para interagir com esses recursos. Cada recurso é identificado por um URI exclusivo, comumente chamado de endpoint de API. Esse é o endereço específico para o qual o cliente envia uma solicitação de API.

O REST é definido pelas seguintes restrições:

• Interface uniforme - cria regras de comunicação padronizadas: todas as solicitações para o mesmo recurso devem ter a mesma aparência. Cada recurso deve ter um URI.
  
  
• Separação de cliente/servidor - as aplicações de cliente e servidor devem poder evoluir separadamente, sem dependências. A única informação que o cliente possui é o URI do recurso.
  
  
• Ausência de estado - o servidor não armazena o estado da sessão entre solicitações. Cada solicitação é autônoma e deve incluir todas as informações necessárias para seu processamento.
  
  
• Capacidade de armazenamento em cache - todos os recursos devem ser armazenáveis em cache quando possível, e o servidor deve declará-los como armazenáveis em cache.
• Arquitetura do sistema em camadas: como cada solicitação em REST é autocontida, o cliente não precisa saber se está se comunicando com o servidor de origem ou um intermediário. Isso torna o REST adequado para APIs públicas que atendem a muitos clientes.
  
  
• Código sob demanda (opcional): as APIs REST geralmente retornam dados. Essa restrição final (a única restrição opcional) permite o retorno de código executável, como JavaScript, que o cliente pode executar quando necessário.

Para uma explicação mais completa dos princípios do REST, entre aqui.

SOAP é um protocolo de mensagens baseado em XML com padrões rigorosos de como as mensagens são estruturadas e transmitidas. Ao contrário das APIs REST, que na prática são executadas quase exclusivamente por HTTP, o SOAP é independente do transporte. Ele pode operar sobre HTTP, SMTP e outros protocolos, tornando-o mais flexível em ambientes corporativos onde o HTTP nem sempre é o protocolo subjacente.

As mensagens SOAP têm uma estrutura rígida que especifica como a mensagem deve ser processada, tornando o SOAP mais detalhado do que o REST, mas também mais padronizado. Os padrões formais, o tratamento de erros embutido e as especificações rígidas de segurança do SOAP permanecem valiosos e impulsionam seu uso contínuo hoje em setores como finanças e saúde.

A RPC é anterior às APIs da web e tem implementações legadas e modernas. A RPC, às vezes conhecida como chamada de sub-rotina ou chamada de função, permite que uma aplicação execute uma função ou método em um servidor remoto como se fosse local. A RPC é organizada em torno de ações em vez de recursos. Em vez de URIs individuais para cada recurso, as APIs RPC normalmente expõem um único endpoint e especificam a ação dentro da carga útil da solicitação.

O antecessor direto do JSON-RPC, o XML-RPC usa XML para codificar suas chamadas e respostas. É mais antigo que o SOAP, porém mais simples, o que facilita a implementação — embora a verbosidade do XML o torne mais pesado do que as alternativas baseadas em JSON. É essencialmente um antecessor direto do JSON-RPC.

O JSON-RPC funciona da mesma forma que o XML-RPC, mas usa JSON em vez de XML. O JSON é mais compacto e fácil de analisar do que o XML, tornando o JSON-RPC mais leve e mais legível do que seu antecessor.

O gRPC é a camada moderna de alto desempenho da família RPC. Foi inicialmente desenvolvido pelo Google e agora é mantido como um projeto de código aberto. Enquanto as implementações de RPC mais antigas utilizam formatos baseados em texto, o gRPC utiliza Protocol Buffers (ou Profobuf), um formato de serialização binária que produz mensagens menores e mais rápidas do que o JSON ou XML.

Também é executado em HTTP/2 em vez de HTTP/1.1, adicionando outros benefícios de desempenho. O gRPC é comumente usado para comunicação interna de microsserviços e é compatível com streaming bidirecional, tornando-o uma forte opção para fluxos de dados em tempo real.

GraphQL é uma linguagem de consulta código aberto e tempo de execução do lado do servidor desenvolvida pelo Facebook em 2012 para facilitar uma busca de recursos mais eficiente. Ele foi projetado para eliminar o overfetching (receber mais dados do que o necessário) e o underfetching (que exige múltiplas requisições para receber os dados necessários), permitindo que os clientes especifiquem exatamente quais dados desejam. O GraphQL usa um único endpoint por meio do qual os clientes podem consultar vários recursos, com os resultados retornados em uma única resposta.

Embora altamente flexível, o GraphQL é mais complicado do que a REST e é mais usado em ambientes complexos, onde os requisitos de dados dos clientes variam significativamente.

Leia uma comparação mais detalhada entre REST e GraphQL aqui.

Todas as APIs mencionadas seguem um modelo de solicitação/resposta iniciado pelo cliente. Vale a pena observar duas exceções importantes em um contexto de integração:

• Os WebSockets (APIs WebSocket) mantêm uma conexão persistente e bidirecional, adequada para casos de uso em tempo real, como feeds de dados em tempo real.
  
  
• Os webhooks invertem completamente o modelo. Em vez de o cliente iniciar uma solicitação, o servidor envia notificações por push ao cliente quando um evento específico ocorre.

As APIs públicas estão totalmente expostas à internet e estão disponíveis para qualquer desenvolvedor ou organização, geralmente sem restrições ou com restrições mínimas. Os desenvolvedores podem ser obrigados a obter uma chave de API, mas, por outro lado, não é necessária muita coisa para trabalhar com essas APIs. Elas são projetadas para incentivar a integração externa e o desenvolvimento de terceiros.

*Não deve ser confundido com a “Especificação da OpenAPI (OAS)”, sobre a qual você pode saber mais aqui. 

As APIs privadas não estão disponíveis para o público e só são acessíveis dentro de uma organização definida. Muitas vezes, elas são isoladas em redes privadas e exigem autenticação rigorosa para acesso. As organizações normalmente usam essas APIs para conectar sistemas de software internos.

Do ponto de vista do acesso, as APIs de parceiros ficam entre as APIs públicas e as privadas, pois estão disponíveis para um grupo específico de parceiros comerciais autorizados. Embora possam ser acessados pela internet pública, não estão disponíveis ao público, e o acesso é concedido apenas a usuários autorizados. As APIs de parceiros são usadas para coisas como compartilhamento de dados B2B ou para monetizar fluxos de dados, e seu uso geralmente é regido por contratos específicos de parcerias. 

*As APIs compostas às vezes são incluídas nesse detalhamento por tipo de acesso, mas são mais bem compreendidas como um padrão de arquitetura do que como um nível de acesso. As APIs compostas combinam chamadas de APIs e podem ser públicas, privadas ou de parceiros. Elas são discutidos mais detalhadamente na seção APIs e microsserviços.

O projeto da API é o processo de tomada de decisão que determina como uma API expõe dados e funcionalidades. No processo de projeto, as equipes decidem quais protocolos e estilos arquitetônicos a API usará, estabelecem convenções consistentes para nomenclatura, estruturas de resposta e tratamento de erros, decidem como o acesso será autenticado e autorizado e definem uma estratégia de versionamento para gerenciar alterações urgentes. Essas e muitas outras decisões moldam como uma API funciona e como os desenvolvedores interagem com ela.

Essencialmente, é um processo que começa com perguntas como: "Como essa API será utilizada?" e avança para desenvolver um blueprint de projeto para APIs que satisfaça as necessidades da organização.

As políticas de governança de APIs de uma organização muitas vezes moldam o projeto de APIs. A governança de APIs refere-se ao conjunto abrangente de normas, políticas e práticas que orientam como uma organização desenvolve, implementa e utiliza suas APIs. Um projeto de APIs eficaz produz APIs que seguem essas políticas predeterminadas.

A documentação da API funciona como um manual técnico que fornece informações sobre uma API, como protocolos compatíveis, linguagens e métodos de autenticação, trechos de código, definições estruturais e outras informações necessárias para os desenvolvedores trabalharem com uma API. Uma documentação de APIs abrangente e atualizada promove uma melhor experiência de APIs para os desenvolvedores e impulsiona a adoção, integração e gerenciamento bem-sucedidos de APIs.

API-first (ou API-design first) é uma abordagem de desenvolvimento de software na qual as APIs são tratadas como a base de uma aplicação, projetadas antes que qualquer código de aplicação seja escrito. Em vez de começar com a lógica de negócios de back-end e a estrutura do banco de dados, as organizações definem o contrato primeiro (muitas vezes usando uma especificação de APIs como o OpenAPI) e constroem o restante da aplicação em torno dele.

É uma abordagem preferida para organizações com uso intenso de integração, preferida por sua escalabilidade, confiabilidade e consistência: a API é a fonte da verdade, e todos os consumidores (apps da web e móveis, dispositivos de Internet das coisas (IoT), apps e modelos de IA e outros sistemas), interagem com a mesma camada de API em vez de integrações personalizadas.

Algumas organizações tratam a API-design first e a API-first como abordagens distintas, sendo esta última uma função mais ampla em toda a organização que trata as APIs como produtos em si, com seus próprios ciclos de vida, gerentes de produtos e roteiros.

Microsserviços é um estilo arquitetônico que divide uma aplicação em serviços menores e independentes. Esses serviços se comunicam por meio de APIs, que geralmente são uma mistura de protocolos e estilos: por exemplo, APIs REST para serviços externos, gRPC para comunicação interna entre serviços e webhooks para fluxos orientados por eventos. Uma arquitetura de microsserviços oferece aos desenvolvedores a flexibilidade de escolher o framework que funciona melhor para um serviço específico.

Também permite que os desenvolvedores testem, implementem, atualizem, integrem, mantenham e escalem serviços independentes uns dos outros. O isolamento de falhas é simplificado (uma única falha de componente não trava toda a aplicação) e, como os serviços são fracamente acoplados, a implementação interna pode mudar com a quebra de integrações.

Um problema comum de microsserviços é o que é conhecido como o problema do "front-end conversacional". Em uma aplicação tradicional, os dados residem em um banco de dados, e um cliente pode consultar esse banco de dados com uma única chamada. Nos microsserviços, os dados estão espalhados por muitos serviços, o que pode exigir que um cliente se comunique com dezenas de serviços, por meio de dezenas de solicitações separadas, para obter os dados necessários. As APIs compostas resolvem esse problema apresentando um endpoint unificado que serve como uma camada de orquestração, atendendo a uma solicitação do cliente, comunicando-se com vários serviços de back-end para coletar os dados solicitados e devolvendo-os ao cliente em uma única carga útil.

As APIs compostas eliminam a necessidade de os clientes fazerem várias chamadas de ida e volta para uma única operação. Elas também ocultam a complexidade do sistema interno: o cliente não precisa saber qual microsserviço lida com quais dados, apenas como chegar ao endpoint composto. E podem reduzir a latência, já que uma única chamada que depende da comunicação interna de microsserviços normalmente é mais rápida do que várias chamadas de ida e volta em uma rede externa.

Apesar de todos os seus benefícios, as arquiteturas de microsserviços expandem a superfície das APIs e adicionam complexidade, destacando a importância de um forte API Management.

API Management é o processo de publicar, proteger, controlar e monitorar APIs ao longo de seu ciclo de vida. Esse trabalho normalmente é centralizado por meio de uma plataforma de gerenciamento de APIs que ajuda as organizações a aplicar políticas uniformes em todas as suas APIs. Muitas dessas plataformas também incluem ferramentas de projeto e documentação, embora esta seção se concentre no papel operacional da gestão.

O API Management inclui a supervisão de:

Um API gateway é uma camada de software que apresenta um único ponto de entrada para os clientes acessarem vários serviços de back-end. Ele evita que os clientes tenham que entender ou interagir com a complexidade da arquitetura por trás do gateway e é usado para controlar a proliferação de APIs criadas por microsserviços.

As principais funções incluem roteamento, autenticação, limitação de taxa e monitoramento. Os gateways também podem lidar com a agregação de solicitações, o que os torna um lugar comum para implementar APIs compostas.

Segurança de APIs é um conjunto de práticas e procedimentos que protegem as APIs e os dados que elas transmitem contra uso indevido, ataques de bots mal-intencionados e outras ameaças à cibersegurança.  A segurança de APIs inclui autenticação (verificação da identidade de um usuário), autorização (determinação do que ele pode fazer), criptografia, validação de entrada e muito mais. Tecnologias de segurança comuns incluem chaves API e OpenID Connect (ODIC) para autenticação e OAuth para autorização. Uma forte postura de segurança de APIs ajuda a garantir que somente usuários e aplicações autorizados acessem as APIs. 

A limitação e a limitação de taxa controlam o volume e o fluxo de solicitações de API para ajudar a manter os sistemas estáveis e disponíveis. A limitação de taxa restringe o número de chamadas que um cliente individual pode fazer em um período específico, e a limitação gerencia o volume de chamadas que um sistema aceita, geralmente desacelerando ou enfileirando solicitações. Os limites de taxas também atendem a uma função comercial, permitindo que as organizações imponham níveis de uso para APIs pagas.

Embora sejam principalmente preocupações operacionais, tanto a limitação quanto o throttling têm uma função de segurança secundária, ajudando a impedir ataques de denial-of-service e de preenchimento de credenciais.

O API Management impõe a estratégia de controle de versão estabelecida no projeto. As plataformas de gerenciamento permitem que as organizações roteiem o tráfego para a versão correta da API, executem várias versões simultaneamente e gerenciem a descontinuação de versões mais antigas. Isso permite que as equipes implementem atualizações e novas versões (até mesmo alterações significativas), ao mesmo tempo em que dá tempo para que as integrações existentes migrem sem interrupções.

As APIs são o tecido conjuntivo entre sistemas corporativos, serviços e parceiros, e é vital entender como funcionam. Uma API com falha pode causar problemas em todas as integrações que dependem dela; o monitoramento e a observabilidade ajudam as equipes a detectar e diagnosticar esses problemas antes que se espalhem pelos sistemas conectados.

O monitoramento de APIs rastreia o desempenho, a disponibilidade, a funcionalidade e o uso das APIs, fornecendo alertas quando métricas como latência ou taxas de erro ultrapassam os limites predefinidos. A observabilidade se expande com base no monitoramento, usando métricas, logs e rastreamentos para obter uma compreensão mais profunda da integridade do sistema e revelar informações que o monitoramento não sinaliza.

Compreender a utilização de APIs ajuda as equipes a planejar a capacidade, lidar com possíveis ameaças e cumprir os requisitos governamentais e regulamentares.

As APIs conectam aplicações de software, sistemas e fluxos de trabalho para a troca de dados e serviços, uma função frequentemente chamada de integração com API. Na maioria das integrações modernas, as APIs são fundamentais para a movimentação de informações entre serviços e sistemas.

Casos de uso empresariais comuns incluem:

As APIs permitem que as equipes integrem serviços de terceiros em suas aplicações e fluxos de trabalho. Por exemplo, se uma empresa de molhos picantes quiser incluir um mapa de localizador de lojas em seu site mostrando os varejistas parceiros, ela pode usar a API de uma aplicação de mapeamento para incorporar essas informações em seu site.

As organizações usam APIs para compartilhar dados e serviços com parceiros, fornecedores e clientes. Uma empresa de logística pode usar uma API para expor informações de rastreamento de pedidos, de modo que os varejistas possam incorporá-las em seus próprios sistemas.

As organizações usam APIs para facilitar a troca de dados entre sistemas corporativos, como plataformas de gerenciamento de relacionamento com o cliente (CRM) e planejamento de recursos empresariais (ERP). Se o endereço de um cliente for atualizado em uma plataforma de CRM, essa mudança poderá ser propagada automaticamente pelos sistemas conectados.

APIs são usadas para acessar ferramentas de IA , como grandes modelos de linguagem (LLMs) e modelos de aprendizado de máquina , além de incorporá-las em aplicações e fluxos de trabalho. A integração de modelos de IA funciona como outras integrações de terceiros: em vez de uma equipe ter que construir e treinar um modelo complexo internamente, ela pode usar uma API para acessar um modelo externo.

Os agentes de IA também usam APIs para acessar serviços e concluir tarefas, mas funcionam de maneira diferente das integrações tradicionais, nas quais um desenvolvedor decide com antecedência quais APIs chamar e como chamá-las. Os agentes de IA tomam essa decisão no tempo de execução e devem ter a liberdade de analisar um problema, escolher uma ferramenta e explorar soluções na hora. Eles precisam de uma forma consistente de descobrir ferramentas e entender como usá-las.

Model Context Protocol (MCP), um código aberto padrão lançado pela Anthropic e agora governado pela Linux Foundation, conecta modelos de IA e agentes com aplicações e sistemas externos, lidando com essa lacuna. Os servidores MCP normalmente ficam sobre as APIs existentes como um "tradutor universal", descrevendo os recursos de uma ferramenta de forma padronizada que qualquer aplicação de IA compatível com MCP pode usar. Em vez de criar uma integração personalizada entre cada aplicação de IA e cada ferramenta, os desenvolvedores podem criar um servidor MCP para uma ferramenta específica e disponibilizá-lo para qualquer agente compatível. O MCP é frequentemente comparado a uma porta USB-C para aplicações de IA, fornecendo um conector padrão em vez de muitos personalizados.

Aplicações móveis e da web usam APIs para se comunicar com seus back-ends e recuperar dados ou acionar ações sem nunca acessar diretamente os bancos de dados ou a lógica de negócios. Uma organização pode construir a funcionalidade de back-end uma vez e usar APIs para atender clientes da web, iOS e Android. Novos canais podem ser adicionados sem a necessidade de reconstruir o back-end.

Algumas organizações dão um passo adiante com uma abordagem de Backend for Frontend, que adiciona camadas finas específicas do cliente sobre APIs compartilhadas, mantendo a lógica de negócios principais em um só lugar.

Algumas aplicações não podem esperar que os clientes solicitem informações. As APIs em tempo real e orientadas por eventos invertem a relação, enviando informações assim que mudam ou quando um evento específico ocorre, em vez de esperar que os clientes solicitem atualizações repetidamente.

Os webhooks notificam os sistemas conectados sobre eventos específicos, enquanto os WebSockets e o streaming gRPC mantêm conexões contínuas para fluxos de dados em andamento. Juntos, alimentam plataformas de negociação financeira, sistemas de chat, jogos multijogadores e troca de dados de sensores de IoT, mantendo os sistemas atualizados sem a necessidade de pesquisas constantes.