Tipos de APIs e como determinar o que será criado

As interfaces de programação de aplicativos — mais comumente chamadas de APIs — fornecem dados e permitem que as empresas conectem sistemas, aplicativos, dispositivos e conjuntos de dados. É importante saber qual tipo de API funcionará melhor para um projeto com base em vários fatores: o caso de uso pretendido, quem usará e acessará essas APIs e os sistemas e conjuntos de dados que precisam ser conectados. Para desempenho de API e API management eficazes, é fundamental determinar o tipo ideal de API para construir e projetar a arquitetura adequadamente.

É raro uma organização decidir do nada que precisa de uma API — na maioria das vezes, as organizações começam com uma ideia, aplicativo, inovação ou caso de uso que requer conectividade com outros sistemas ou conjuntos de dados.

As APIs entram em cena como um meio de viabilizar a conectividade entre os sistemas e conjuntos de dados que precisam ser integrados.

As organizações podem usar diferentes tipos de APIs para diferentes fins: desde expor a funcionalidade de um sistema central internamente até habilitar um app mobile voltado para o cliente. A conectividade API-led da MuleSoft inclui três categorias de APIs:

• APIs de sistema: disponibilizam dados de sistemas centrais de registro dentro de uma organização. Exemplos de sistemas críticos dos quais as APIs podem disponibilizar dados incluem ERP, sistemas de clientes e de faturamento e bancos de dados próprios.
• APIs de processo: interagem e moldam os dados em um único sistema ou entre sistemas — eliminando os silos de dados. As APIs de processo fornecem um meio de combinar dados e orquestrar várias APIs de sistema para uma finalidade comercial específica. Exemplos disso incluem criar uma visão 360 graus do cliente, do processamento do pedido e do status do envio.
• APIs de experiência: fornecem um contexto de negócios para os dados e processos que foram disponibilizados e estabelecidos com as APIs de sistema e processo. As APIs de experiência expõem os dados a serem consumidos por seu público-alvo — como aplicativos mobile, portais internos de dados de clientes etc.

Depois de determinar o caso de uso para as APIs de sua organização, é preciso determinar quem acessará essas APIs. Na maioria das vezes, o caso de uso e o usuário pretendido andam de mãos dadas — por exemplo, você pode querer exibir dados do cliente para seus agentes de vendas e serviços internos, o usuário final pretendido que, neste caso, são os funcionários internos.

Abaixo estão três tipos de APIs baseadas em como são gerenciadas e por quem são acessadas:

External APIs can be accessed by third-parties (developers, partners, etc.) that are external to the organization. They often make an organization's data and services easily accessible on a self-service basis by developers around the world who are looking to create innovative applications and integrations.

An example of an open API is the Google Maps API that is used across third-party applications (such as ridesharing and food delivery apps) to enable location tracking and mapping.

Internal APIs are the opposite of open APIs in that they are inaccessible to external consumers and only available to an organization’s internal developers. Internal APIs can enable enterprise-wide initiatives from the adoption of DevOps and microservice architectures to legacy modernization and digital transformation. The use and reuse of these APIs can enhance an organization's productivity, efficiency, and agility.

An example of a reusable internal API is if a call center team created a customer information API used in a call center application to access their name, contact information, account info, etc. That team can then reuse this same API in a customer-facing web application or mobile application.

As APIs de parceiro ficam em algum lugar no meio das APIs internas e externas. Essas APIs são acessadas por outras pessoas fora da organização com permissões exclusivas. Normalmente, esse acesso especial é concedido a terceiros específicos para facilitar uma parceria comercial estratégica.

Um caso de uso comum de uma API de parceiro é quando duas organizações querem compartilhar dados entre si — como o departamento de saúde de uma cidade e um hospital dessa cidade. Uma API de parceiro seria configurada para que cada organização tenha acesso aos dados necessários com o conjunto certo de credenciais e permissões.

Outra área de escolha para uma API é o estilo ou os estilos arquitetônicos que serão empregados. É fundamental escolher um estilo ou padrão arquitetônico que dê melhor suporte ao uso pretendido da API se determinados recursos funcionais forem necessários. Isso tende a ser uma decisão de design de API tomada por equipes com maior inclinação técnica.

Antes de tomar essa decisão, você precisará ter uma compreensão básica de qual infraestrutura já está instalada — se os sistemas são locais ou baseados em nuvem, quais sistemas e conjuntos de dados precisam ser usados, quais protocolos de segurança precisam ser implementados e quais funcionalidades são necessárias. No caso do design que prioriza a API, a funcionalidade e as experiências de usuário desejadas devem embasar as mudanças no estado de TI legado em vez de permitir que o status quo do estado de TI legado dite a funcionalidade ou experiência.

Há vários estilos de arquitetura para APIs, bem como diversos formatos de dados dentro desses estilos. Listamos abaixo alguns dos mais comuns:

• REST: REST (Representational State Transfer) é um estilo de arquitetura que separa as preocupações do consumidor da API do provedor da API, usando comandos integrados ao protocolo de rede subjacente. Os clientes usam os links e formulários incluídos para executar ações (como ler, atualizar, compartilhar, aprovar etc.). HTML é o exemplo mais conhecido desse estilo e existem vários outros formatos apenas para APIs (HAL, CollectionJSON, Siren etc.). As APIs REST oferecem muitos benefícios — incluindo flexibilidade e capacidade de acomodar formatos de dados populares, como JSON e XML, entre outros.
• RPC: as chamadas de procedimento remoto — ou RPCs — normalmente exigem que os desenvolvedores executem blocos específicos de código em outro sistema. A invocação remota de procedimentos estilo RPC de outros sistemas geralmente requer que os desenvolvedores chamem esses procedimentos pelo nome. O RPC é agnóstico em termos de protocolo, o que significa que tem o potencial de ser compatível com muitos protocolos, mas também perde os benefícios de usar recursos nativos do protocolo (como o armazenamento em cache). A proliferação de nomes de procedimento não padrão de uma API RPC para outra resulta em um acoplamento mais forte entre consumidores e provedores de API que, por sua vez, sobrecarrega os desenvolvedores envolvidos em todos os aspectos de um ecossistema de APIs baseado em RPC. Os padrões de arquitetura RPC podem ser observados em tecnologias populares de API, como SOAP, GraphQL e gRPC.
• Baseadas em eventos/Streaming: às vezes chamadas de arquiteturas de eventos, em tempo real, de streaming, assíncronas ou push, as APIs baseadas em eventos não esperam que um consumidor de API as chame para enviar uma resposta. Em vez disso, uma resposta é disparada pela ocorrência de um evento. Esses serviços expõem eventos nos quais os clientes podem se inscrever para receber atualizações quando os valores no serviço mudam. Há muitas variações para esse estilo, incluindo (entre outros) reativo, publicação e assinatura, notificação de eventos e CQRS.

Estamos cercados por todos os tipos de eventos aos quais esse padrão de API é adequado. Aqui citamos alguns:

• Uma conta do Twitter emite um novo tweet.
• A temperatura em um termômetro remoto muda.
• Um veículo passa por um sensor na calçada.
• Uma câmera de segurança detecta movimento em seu campo de visão.
• Uma máquina de eletrocardiografia detecta um batimento cardíaco irregular.
• Uma porta de saída de emergência é aberta.
• Um detector de fumaça detecta fumaça.

O design e o gerenciamento eficazes de APIs exigem muitas considerações. O conteúdo acima deve fornecer um instantâneo das diferentes decisões que as organizações precisam tomar ao se prepararem para projetar, implementar e gerenciar uma API. Para obter mais informações, faça download do nosso whitepaper sobre conectividade API-led.