O que é uma API?

API significa interface de programação de aplicações, que é um conjunto de definições e protocolos para desenvolver e integrar software.

As APIs permitem que o seu produto ou serviço se comunique com outros produtos e serviços sem que seja necessário saber como eles foram implementados. Isso simplifica o desenvolvimento de apps, economizando tempo e dinheiro. Ao projetar novas ferramentas e produtos, ou gerenciar os existentes, as APIs oferecem flexibilidade, simplificam o design, a administração e o uso e oferecem oportunidades de inovação.

As APIs são, por vezes, entendidas como contratos e a sua documentação representa o acordo estabelecido entre as partes: se uma parte enviar uma solicitação remota em um formato específico, o software da outra parte responderá no mesmo formato.

Como as APIs simplificam como os desenvolvedores integram novos componentes de aplicações a uma arquitetura preexistente, elas ajudam na colaboração entre as equipes de negócios e de TI. Muitas vezes, as demandas empresariais mudam rapidamente em resposta às constantes mudanças nos mercados digitais, onde novos concorrentes podem mudar toda uma indústria com uma nova app. Para manter a competitividade, é importante viabilizar o rápido desenvolvimento e a implantação de serviços inovadores. O desenvolvimento de aplicações nativas em nuvem é uma forma reconhecida de acelerar o desenvolvimento e depende da conexão de uma arquitetura de aplicações baseada em microsserviços por meio de APIs.

As APIs são uma maneira simplificada de conectar sua própria infraestrutura por meio do desenvolvimento de apps nativas em nuvem. No entanto, elas também permitem compartilhar dados com clientes e outros usuários externos. As APIs públicas representam um valor de negócio único porque podem simplificar e expandir como você se conecta com seus parceiros, além de potencialmente monetizar seus dados (a API do Google Maps é um exemplo bastante conhecido).

Por exemplo, imagine uma empresa de distribuição de livros. A distribuidora de livros poderia oferecer aos clientes uma app em nuvem para os atendentes de uma livraria verificarem a disponibilidade dos livros. O desenvolvimento dessa app pode ser caro, limitado pela plataforma e exigir longos períodos de desenvolvimento e manutenção contínua.

Como alternativa, a distribuidora pode oferecer uma API para verificar a disponibilidade no estoque. Há vários benefícios nessa abordagem:

• Permitir que os clientes acessem os dados por meio de uma API os ajuda a agregar informações sobre o inventário em um único local.
• A distribuidora de livros pode fazer alterações em seus sistemas internos sem afetar os clientes, contanto que o comportamento da API não seja alterado.
• Com uma API disponível publicamente, os desenvolvedores que trabalham para a distribuidora de livros, vendedores de livros ou terceiros podem desenvolver uma app para ajudar os clientes a encontrarem os livros que procuram. Isso pode aumentar as vendas ou criar outras oportunidades de negócios.

Em resumo, com as APIs, você libera o acesso aos seus recursos sem abrir mão da segurança e do controle. É você quem decide como isso será feito e quem terá acesso. A segurança das APIs está relacionada ao bom gerenciamento, o que inclui o uso de um gateway de APIs. É possível se conectar a APIs e criar aplicações que consomem os dados ou funcionalidades disponibilizados por elas usando uma plataforma de integração distribuída que conecta tudo, incluindo sistemas legados e a Internet das Coisas (IoT).

Expor suas APIs a parceiros ou ao público pode:

• Criar novos canais de receita ou ampliar os existentes.
• Expandir o alcance da sua marca.
• Viabilizar a inovação aberta ou melhorar a eficiência por meio da colaboração e do desenvolvimento externos.

Parece ótimo, não é? Mas como as APIs podem fazer tudo isso?

Vamos voltar ao exemplo da distribuidora de livros.

Imagine que um dos parceiros da empresa desenvolve uma app que ajuda as pessoas a encontrarem livros nas prateleiras da livraria. Essa experiência aprimorada atrai mais compradores para a livraria (que é cliente da distribuidora) e amplia o canal de receita existente.

Talvez um terceiro use uma API pública para desenvolver uma app que permita às pessoas comprar livros direto com a distribuidora, em vez de em uma loja física. Isso abre um novo canal de receita para a distribuidora de livros.

Compartilhar APIs com parceiros específicos ou com o mundo todo pode ter efeitos positivos. Cada parceria aumenta o reconhecimento da sua marca para além das iniciativas de marketing da sua empresa. Disponibilizar a tecnologia para todos, como acontece com uma API pública, incentiva os desenvolvedores a criar um ecossistema de apps em torno da sua API. Quanto mais pessoas usarem sua tecnologia, maior será a probabilidade de elas fazerem negócios com você.

Tornar a tecnologia pública pode gerar resultados novos e inesperados. Às vezes, esses resultados transformam indústrias inteiras. Para a nossa distribuidora de livros, novas empresas (como um serviço de empréstimo de livros, por exemplo) podem mudar completamente como fazemos negócios. Com as APIs públicas e de parceiros, você aproveita a criatividade de uma comunidade maior do que sua equipe interna de desenvolvimento. Novas ideias podem surgir de qualquer lugar, e as empresas precisam estar cientes das mudanças no mercado e prontas para agir de acordo com elas. As APIs podem ajudar.

As APIs surgiram nos primeiros dias da computação, muito antes do computador pessoal (PC). Na época, uma API era normalmente usada como uma biblioteca para sistemas operacionais. A API era quase sempre local para os sistemas em que operava, embora às vezes permitisse a troca de mensagens entre mainframes. Após quase 30 anos, as APIs abandonaram seus ambientes locais. No início dos anos 2000, elas estavam se tornando uma tecnologia importante para a integração remota de dados.

As APIs remotas são feitas para interagir por meio de uma rede de comunicações. Quando falamos remotamente, significa que os recursos manipulados pela API estão em algum lugar fora do computador que faz a solicitação. Como a rede de comunicações mais usada é a internet, a maioria das APIs é projetada com base em padrões da web. Nem todas as APIs remotas são APIs web, mas é justo supor que as APIs web são remotas.

As APIs web normalmente usam HTTP para enviar solicitações e oferecem uma definição da estrutura das mensagens de resposta. No geral, essas mensagens têm a forma de um arquivo XML ou JSON. Ambos são formatos recomendados porque apresentam os dados de forma simplificada, o que facilita a manipulação por outras apps.

Com a expansão das APIs web, foi desenvolvida uma especificação de protocolo para ajudar a padronizar a troca de informações: Simple Object Access Protocol, mais conhecido como SOAP. As APIs projetadas com SOAP usam XML como formato de mensagem e recebem solicitações por HTTP ou SMTP. O SOAP facilita o compartilhamento de informações entre apps executadas em ambientes diferentes ou escritas em linguagens diferentes.

Outra especificação é a Representational State Transfer (REST). As APIs web que seguem as restrições arquitetônicas da REST são chamadas de APIs RESTful. A REST difere do SOAP em um aspecto fundamental: o SOAP é um protocolo, enquanto a REST é um estilo de arquitetura. Isso significa que não há um padrão oficial para as APIs web RESTful. Conforme definido na dissertação de Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures", as APIs são RESTful desde que estejam em conformidade com as seguintes restrições de um sistema RESTful:

• Arquitetura cliente-servidor: a arquitetura REST é composta por clientes, servidores e recursos e lida com solicitações por HTTP.
• Característica stateless: nenhum conteúdo do cliente é armazenado no servidor entre as solicitações. Em vez disso, as informações sobre o estado da sessão são mantidas com o cliente.
• Capacidade de armazenamento em cache: o armazenamento em cache pode eliminar a necessidade de algumas interações entre cliente e servidor.
• Sistema em camadas: as interações entre cliente e servidor podem ser mediadas por camadas adicionais. Essas camadas podem oferecer mais funcionalidades, como balanceamento de carga, caches compartilhados ou segurança.
• Código sob demanda (opcional): os servidores podem estender a funcionalidade de um cliente transferindo o código executável.
• Interface uniforme: essa restrição é essencial para o design de APIs RESTful e inclui quatro facetas:
  • Identificação de recursos em solicitações: os recursos são identificados nas solicitações e separados das representações retornadas ao cliente.
  • Manipulação de recursos por meio de representações: os clientes recebem arquivos que representam recursos. Essas representações devem ter informações suficientes para permitir a modificação ou exclusão.
  • Mensagens autoexplicativas: cada mensagem retornada para o cliente tem informações suficientes para detalhar como ele deve processá-las.
  • Hipermídia como mecanismo do estado da aplicação: depois de acessar um recurso, o cliente REST deve ser capaz de descobrir por meio de hiperlinks todas as outras ações que estão disponíveis no momento.

Essas restrições podem parecer muitas, mas são muito mais simples do que um protocolo predefinido. Por esse motivo, as APIs RESTful estão se tornando mais predominantes do que o SOAP.

Nos últimos anos, a especificação OpenAPI se consolidou como um padrão comum para a definição de APIs REST. A OpenAPI estabelece uma maneira independente de linguagem para os desenvolvedores criarem interfaces de API REST. Dessa forma, os usuários as entendem com o mínimo de dúvidas.

Outro padrão de API que está surgindo é o GraphQL, uma linguagem de consulta e runtime do lado do servidor que é uma alternativa à REST. O GraphQL prioriza fornecer aos clientes exatamente os dados solicitados e nada mais. Como alternativa à REST, o GraphQL permite que os desenvolvedores criem solicitações que extraem dados de múltiplas fontes em uma única chamada de API.

Confira mais informações sobre SOAP vs. REST

As duas abordagens de arquitetura que mais usam APIs remotas são a arquitetura orientada a serviço (SOA) e a de microsserviços. A SOA, a mais antiga das duas abordagens, começou como uma melhoria em relação às apps monolíticas. Enquanto uma única app monolítica faz tudo, algumas funções podem ser fornecidas por diferentes apps levemente acopladas por meio de um padrão de integração, como um enterprise service bus (ESB).

Em muitos aspectos, a SOA é mais simples do que uma arquitetura monolítica, mas ela traz o risco de alterações em cascata por todo o ambiente se as interações dos componentes não forem compreendidas com clareza. Essa complexidade adicional reintroduz alguns dos problemas que a SOA buscava solucionar.

As arquiteturas de microsserviços são semelhantes aos padrões SOA no uso de serviços especializados e com baixo acoplamento. Mas elas levam a fragmentação das arquiteturas tradicionais ainda mais longe. Os serviços na arquitetura de microsserviços usam um framework de mensagens comum, como as APIs RESTful. Eles usam APIs RESTful para se comunicarem sem transações difíceis de conversão de dados ou camadas de integração adicionais. O uso de APIs RESTful permite e até incentiva a entrega mais rápida de novas funcionalidades e atualizações. Cada serviço é independente. Um serviço pode ser substituído, aprimorado ou descartado sem afetar outros na arquitetura. Essa arquitetura leve ajuda a otimizar recursos distribuídos ou em nuvem e oferece suporte à escalabilidade dinâmica para serviços individuais.

Mais informações sobre SOAs

Um webhook é uma função de callback baseada em HTTP que viabiliza a comunicação leve e orientada por eventos entre duas APIs. Os webhooks são usados por várias apps web para receber pequenos volumes de dados de outras apps, mas também podem ser utilizados para acionar fluxos de trabalho de automação nos ambientes do GitOps.

Em geral, os webhooks são descritos como APIs reversas ou APIs de push porque colocam a responsabilidade da comunicação no servidor, e não no cliente. Em vez de o cliente enviar as solicitações HTTP pedindo os dados até receber uma resposta, o servidor envia para o cliente uma solicitação HTTP POST exclusiva quando os dados estão disponíveis. Apesar dos apelidos, os webhooks não são APIs. Eles trabalham juntos. Uma aplicação precisa ter uma API para usar um webhook. 

Mais informações sobre webhooks

O Model Context Protocol (MCP) e as APIs atuam como pontes digitais que permitem a conexão entre sistemas distintos. As capacidades do MCP são desenvolvidas com base nas APIs, portanto o protocolo não existiria sem elas. 

As tecnologias se diferenciam em seu funcionamento e propósito:

• O MCP conecta modelos de linguagem a ferramentas e dados externos, viabilizando fluxos de trabalho que se adaptam e improvisam em tempo real. 
• Os fluxos de trabalho de API tradicionais seguem um conjunto fixo de regras. Depois que os dois sistemas são conectados, as interações ficam limitadas a um conjunto específico de ações programadas por um desenvolvedor.

Mais informações sobre MCP vs. APIs