Dependendo de como você deseja categorizá-las, existem vários tipos diferentes de APIs, e eles têm diversos escopos, benefícios e públicos-alvo, o que torna cada um deles adequado de forma única para diferentes fins.
As APIs vêm em diferentes formas e tamanhos, dando aos desenvolvedores a flexibilidade de escolher o tipo de APIs que melhor se adequa aos seus propósitos. Uma distinção popular é categorizá-las pelo público-alvo, o que nos dá as seguintes três categorias: APIs Públicas, APIs de Parceiros e APIs Internas. Também adicionaremos uma categoria de bônus, APIs Compostas, que não se encaixa perfeitamente em nenhum desses grupos.
É claro que não há apenas uma maneira de categorizar APIs: você pode classificá-las por uso empresarial, por tipo vertical ou técnico, ou por estilo/protocolo (SOAP, REST, Assíncrono, GraphQL etc.).
APIs Públicas
As APIs públicas, também chamadas de APIs externas ou abertas, estão disponíveis publicamente para desenvolvedores e outros usuários com mínimas restrições. Elas podem exigir registro, uma Chave de API ou OAuth.
Algumas podem até ser completamente abertas — na verdade, embora os termos público e aberto sejam frequentemente usados de forma intercambiável, nem todas as APIs públicas são abertas. (E para complicar ainda mais as coisas, Open API e OpenAPI são duas coisas diferentes!)
Quando as observamos em termos de público-alvo, as APIs públicas concentram-se em usuários externos para acessar dados ou serviços.
Exemplos e casos de uso de APIs Públicas
A ciência é um campo onde você verá muita troca de informações livre e aberta, frequentemente por meio de APIs. Um bom exemplo é o portal de API aberta da NASA, que permite que os desenvolvedores assinem seus dados, como sua popular API de Imagem Astronômica do Dia. Outra API disponibiliza dados de projetos de tecnologia da NASA em um formato legível por máquina.
Muitos dos esforços de rastreamento de contatos durante a pandemia de Covid-19 também são bons exemplos de aplicativos que alavancaram APIs públicas. Por exemplo, uma API que permite o compartilhamento de dados entre várias agências governamentais terá requisitos de governança e segurança significativamente mais rigorosos e complexos do que uma API usada por apenas uma equipe em um único departamento do governo.
Como funcionam as APIs Internas?
As APIs internas, também conhecidas como APIs Privadas, são ocultadas dos usuários externos e expostas apenas pelos sistemas internos. As APIs internas não são destinadas ao consumo fora da empresa, mas sim para uso entre equipes de desenvolvimento internas para melhorar a produtividade e a reutilização de serviços.
Praticamente todo mundo está usando APIs internas hoje em dia: muitas empresas começam construindo uma API em cima de um banco de dados interno. Um bom processo de governança envolve expô-las em um portal de API interno que se conecta aos sistemas IAM internos para autenticar e permitir que os usuários acessem o conjunto certo de APIs.
A distinção entre interno/externo, privado/público pode causar dor de cabeça quando se trata de segurança, por isso uma abordagem de Zero Trust— tratando todas as APIs como se pudessem ser expostas — é uma abordagem mais forte para a segurança de API.
Exemplos de APIs Internas/Privadas
Jeff Bezos estabeleceu o padrão na Amazon quando emitiu o que hoje é conhecido como o mandato de API: que todas as capacidades teriam que ser projetadas e expostas como APIs.
Seguindo esse modelo, as APIs internas permitem que diferentes partes do sistema de uma empresa se comuniquem e compartilhem dados com segurança. Exemplos poderiam incluir:
- APIs de autenticação e logins de usuários e verificar sua indentidade dentro do ecossistema da empresa. Isso garante que apenas pessoal autorizado possa acessar recursos específicos ou realizar determinadas ações.
- APIs de recuperação de dados para coletar dados de vários bancos de dados ou sistemas internos mediante solicitação. Pense nisso como um bibliotecário buscando livros específicos nas prateleiras da biblioteca — ele recupera os dados certos quando necessário, tornando-os acessíveis para análise ou uso em outras aplicações.
- APIs de automação de fluxo de trabalho para tarefas ou processos repetitivos dentro do fluxo de trabalho da empresa. Por exemplo, poderia gerar relatórios automaticamente, agendar tarefas ou acionar ações com base em determinadas condições.
- APIs de notificação/alerta com base em gatilhos ou eventos predefinidos, essas ajudam a manter todos informados, entregando atualizações em tempo real sobre o status do sistema, ações do usuário ou outros acontecimentos importantes.
O que são APIs de Parceiros?
As APIs de Parceiros são APIs expostas por/para os parceiros de negócios estratégicos. Elas não estão disponíveis publicamente e precisam de autorização específica para acessá-las. Como as APIs abertas/públicas, as APIs de parceiros são a ponta do iceberg porque são as mais visíveis e são usadas para comunicar além dos limites da empresa.
Elas geralmente são expostas em um portal de desenvolvedor de API público que os desenvolvedores podem acessar no modo de autoatendimento. Enquanto as APIs abertas/públicas são completamente abertas, há um processo de integração com um fluxo de validação específico para acessar as APIs de parceiros.
Por que você pode precisar de uma API composta?
Por fim, as APIs compostas combinam vários dados ou serviços de APIs. Elas são construídas usando as capacidades de orquestração de API de uma ferramenta de criação de API. Elas permitem que os desenvolvedores acessem vários pontos de extremidade em uma única chamada.
As APIs compostas são úteis, por exemplo, em um padrão de arquitetura de microsserviços onde você precisa de informações de vários serviços para realizar uma única tarefa.
APIs de dados e serviços
Além da diferença entre APIs Internas, de Parceiros e abertas/externas, devemos mencionar outra abordagem para categorizar APIs:
- APIs de dados fornecem acesso CRUD a conjuntos de dados subjacentes para vários bancos de dados ou provedores de nuvem SaaS. Essas APIs são necessárias para servir alguns dados fundamentais provenientes de aplicativos SaaS, com a ajuda de conectores SaaS ou armazenamentos de dados internos. Portais legados, por exemplo, onde o login e a senha são salvos no arquivo web.config, são um dos exemplos mais comuns.
- APIs de serviço interno expõem serviços internos, refletindo partes dos processos internos ou algumas ações complexas.
- APIs de serviço externo são serviços de terceiros que podem ser incorporados nos serviços existentes da empresa para trazer valor adicional.
- APIs de experiência do usuário aproveitam APIs compostas para ajudar os desenvolvedores de aplicativos a fornecer a experiência certa para cada tipo de dispositivo (desktop, móvel, tablet, VPA, IoT).
O que é uma API REST?
REST (abreviação de Representational State Transfer) é uma API de serviços da web. As APIs REST são cruciais para aplicativos da web modernos, incluindo Netflix, Uber, Amazon, etc. Para uma API ser RESTful, ela deve seguir as seguintes regras:
- Sem estado — Uma API REST é, por natureza, uma Arquitetura Cliente-Servidor sem estado.
- Interface uniforme — Um cliente e um servidor devem se comunicar via HTTP (Protocolo de Transferência de Hipertexto) usando URIs (Identificadores de Recursos Únicos), CRUD (Criar, Ler, Atualizar, Excluir) e convenções JSON (Notação de Objeto JavaScript).
- Cliente-Servidor — O cliente e o servidor devem ser independentes um do outro. As mudanças feitas no servidor não devem afetar o cliente e vice-versa.
- Cache — O cliente deve armazenar em cache as respostas, pois isso melhora a experiência do usuário tornando-as mais rápidas e eficientes.
- Em camadas — A API deve suportar uma arquitetura em camadas, com cada camada contribuindo para uma hierarquia clara. Cada camada deve ser facilmente acoplada e permitir encapsulamento.
As APIs desempenham um papel vital no desenvolvimento de qualquer aplicativo. E REST se tornou o padrão preferido para a construção de aplicativos que se comunicam pela rede.
Entendendo as APIs SOAP
SOAP (Protocolo Simples de Acesso a Objetos) é um protocolo bem estabelecido, semelhante ao REST no sentido de ser um tipo de API da Web.
O SOAP tem sido utilizado desde o final da década de 1990. O SOAP foi o primeiro a padronizar a forma como as aplicações devem usar conexões de rede para gerenciar serviços.
Mas o SOAP veio com regras estritas, padrões rígidos eram muito pesados e, em algumas situações, muito intensivos em recursos. Exceto para cenários existentes nas instalações, a maioria dos desenvolvedores agora prefere desenvolver em REST em vez de SOAP.
O que é uma API gRPC?
As APIs gRPC são baseadas na tecnologia de Chamada de Procedimento Remoto (RPC), mas com uma reviravolta – elas usam HTTP/2, um protocolo mais avançado que oferece melhor desempenho e suporta recursos como streaming bidirecional e multiplexação.
As APIs gRPC podem aproveitar Protocol Buffers (Protobuf) como um protocolo de serialização. Isso significa que os dados são codificados em um formato binário compacto e eficiente, tornando a transmissão mais rápida e reduzindo o uso de largura de banda em comparação com formatos tradicionais baseados em texto, como JSON ou XML.
Um aspecto-chave do gRPC é seu suporte a várias linguagens de programação, permitindo que os desenvolvedores criem APIs e comunicação cliente-servidor de forma transparente, independentemente das linguagens de programação que eles usam. Essa flexibilidade torna o gRPC ideal para a construção de sistemas distribuídos e arquiteturas de microsserviços.
Em resumo, as APIs gRPC oferecem uma maneira moderna, de alto desempenho e independente de linguagem para que os componentes de software se comuniquem, tornando-as adequadas para a construção de sistemas distribuídos e eficientes.
Definindo APIs GraphQL
O GraphQL não é estritamente um protocolo de API, mas oferece uma maneira poderosa para que os clientes interajam com dados armazenados em um servidor ou banco de dados. Ao contrário das APIs REST tradicionais, onde os clientes estão limitados a pontos de extremidade predefinidos, o GraphQL permite que os clientes façam consultas e recuperem precisamente os dados de que precisam, em uma única solicitação, usando uma sintaxe flexível e intuitiva.
No seu cerne, o GraphQL é uma linguagem de consulta que permite que os clientes descrevam a estrutura dos dados de que precisam, e o servidor responde exatamente com esses dados. Essa abordagem fornece aos clientes uma compreensão completa dos dados disponíveis e permite que eles busquem dados relacionados em uma única solicitação, reduzindo os problemas de sobrecarga ou subcarga comuns encontrados nas APIs REST.
Uma das principais vantagens do GraphQL é sua capacidade de se sobrepor a bancos de dados inteiros, permitindo que os clientes acessem uma ampla gama de dados com consultas específicas. Isso o torna particularmente adequado para aplicações com requisitos de dados complexos, como redes sociais, plataformas de comércio eletrônico ou painéis intensivos em dados.
Além disso, a linguagem humanizada do GraphQL facilita até mesmo para não desenvolvedores escrever e entender consultas.
APIs orientadas a eventos, também conhecidas como APIs assíncronas
Nos últimos anos, as APIs orientadas a eventos ou assíncronas ganharam destaque porque oferecem uma excelente solução para alguns pontos e casos de uso específicos em nosso mundo sempre ligado e rico em dados.
As APIs orientadas a eventos diferem das APIs REST pela forma como transmitem informações em tempo quasi real. Elas são particularmente úteis em casos como rastreadores de mercado de ações, que exigem dados constantemente atualizados, ou dispositivos IoT que monitoram eventos em tempo real.
Para esse tipo de dados, usar uma arquitetura REST exigiria solicitações constantes e onerosas para um servidor — muito parecido com uma criança perguntando “já chegamos?” no banco de trás do carro em uma viagem.
Uma arquitetura orientada a eventos (EDA) permite que a fonte envie uma resposta apenas quando as informações são novas ou mudaram. Existem algumas maneiras de alcançar esse resultado, e alguns padrões de interação de API orientados a eventos populares são Webhook, Websocket e streaming.
Empacotar capacidades digitais discretas como APIs torna possível recombinar as coisas mais rapidamente, dando às empresas a flexibilidade de construir novos produtos e serviços a partir de APIs existentes, contribuir com novas capacidades como blocos de construção para a plataforma e melhorar o espaço da solução tornando todas as capacidades disponíveis para reutilização.
Autor
Colaboradora: Lydia Defranchi
Editora-chefe e jornalista do blog na Axway.com
