Integração

O que são APIs?

A interface de programação de aplicativos (API) é um conjunto de ferramentas, definições e protocolos usado para o desenvolvimento de software de aplicativos. Com ela, sua solução ou serviço pode se comunicar com outros produtos e serviços sem precisar saber como eles foram implementados. As APIs ajudam a simplificar o desenvolvimento de aplicativos, gerando economia de tempo e dinheiro para as empresas. Ao desenvolver novas ferramentas e soluções (ou gerenciar as existentes), as APIs oferecem a flexibilidade necessária para simplificar o design, a administração e o uso, além de fornecer oportunidades de inovação.

Por exemplo, imagine uma empresa distribuidora de livros. Essa distribuidora poderia oferecer aos clientes um aplicativo em que os atendentes de uma livraria pudessem verificar a disponibilidade de um título diretamente com a distribuidora. Esse aplicativo poderia ser caro de desenvolver, limitado por plataforma e exigiria longos períodos de desenvolvimento e manutenção contínua.

Como alternativa, a distribuidora de livros poderia fornecer uma API para verificar a disponibilidade no estoque. Essa abordagem proporciona vários benefícios, incluindo:

  • O acesso aos dados por meio de uma API ajuda os clientes a agregarem informações sobre o inventário em um único local.
  • A distribuidora de livros pode fazer alterações nos sistemas internos sem causar impacto nos clientes, contanto que o comportamento da API não mude.
  • Com uma API publicamente disponível, os desenvolvedores que trabalham para a distribuidora de livros, os vendedores ou terceiros poderiam desenvolver um aplicativo para ajudar os clientes a encontrar os livros que procuram. Isso poderia resultar no aumento das vendas ou outras oportunidades de negócios.

Para resumir, as APIs permitem que você abra o acesso aos seus recursos, sem deixar de manter a segurança e o controle. Como isso será feito e quem terá acesso será determinado por você. É possível conectar-se a APIs, bem como criar as aplicações que consomem os dados ou as funcionalidades expostas por essas APIs, por meio de uma plataforma de integração distribuída que conecta todos os elementos, incluindo sistemas legados e dispositivos de Internet das Coisas (IoT).

Existem três abordagens a políticas de lançamento de API.

Privado

A API é usada apenas internamente. Isso oferece às empresas um maior controle sobre as APIs.

Parceiros

A API é compartilhada com parceiros de negócios específicos. Isso pode fornecer fluxos de receita adicionais sem comprometer a qualidade.

Público

A API é disponibilizada para todos. Com isso, terceiros podem desenvolver aplicativos que interajam com a sua API, e isso pode ser uma fonte de inovação.

Inovação com APIs

A exposição das suas APIs aos parceiros ou ao público pode:

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

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

Vamos voltar para o exemplo da empresa distribuidora livros.

Vamos supor que um dos parceiros da empresa desenvolva um aplicativo que ajude as pessoas a encontrar livros nas prateleiras de livrarias. Essa experiência aprimorada gera mais compradores à livraria (o cliente da distribuidora) e amplia o canal de receita existente.

Talvez um terceiro use uma API pública para desenvolver um aplicativo que possibilite que as pessoas comprem livros diretamente da distribuidora em vez de uma livraria. Isso abre um novo canal de receita para a distribuidora de livros.

O compartilhamento de APIs (com parceiros selecionados ou aberta a todos) pode ter efeitos positivos. Cada parceria amplia o reconhecimento da sua marca além dos esforços de marketing da sua empresa. Abrir a tecnologia para todos, assim como com a API pública, estimula os desenvolvedores a criar um ecossistema de aplicativos com base na sua API. Se mais pessoas usam sua tecnologia, isso aumenta o número de pessoas que provavelmente fariam negócios com você.

Tornar a tecnologia pública pode gerar resultados novos e inesperados. Às vezes, esses resultados revolucionam setores inteiros. No caso da nossa empresa distribuidora de livros, novas organizações (um serviço de empréstimos de livros, por exemplo) podem mudar fundamentalmente a maneira de fazer negócios. Com as APIs públicas e de parceiros, você pode se beneficiar dos esforços criativos de uma comunidade muito maior do que sua equipe de desenvolvedores internos. Novas ideias podem surgir de qualquer lugar. Além disso, as empresas precisam estar cientes das mudanças nos próprios setores e prontas para agir. As APIs podem ajudar.

Um breve histórico sobre as APIs

As APIs emergiram nos primeiros dias da computação, muito antes do computador pessoal. Naquela época, uma API normalmente era usada como uma biblioteca para sistemas operacionais. Embora a API enviasse mensagens entre mainframes em alguns momentos, ela era quase sempre local para os sistemas em que operava. Depois de quase 30 anos, as APIs se expandiram para além dos ambientes locais. No início dos anos 2000, elas estavam se tornando uma tecnologia importante para a integração remota de dados.

APIs remotas

As APIs remotas foram projetadas para interagir por meio de uma rede de comunicações. Quando falamos “remota”, queremos dizer que os recursos manipulados pela API estão em algum lugar fora do computador fazendo a solicitação. Como a rede de comunicações mais usada é a Internet, a maioria das APIs são projetadas com base em padrões da web. Nem todas as APIs remotas são da web. No entanto, é normal supor que as APIs da web sejam remotas.

As APIs da web normalmente usam HTTP para mensagens de solicitação e fornecem uma definição da estrutura das mensagens de resposta. Essas mensagens de resposta geralmente têm o formato de arquivo XML ou JSON. Tanto XML quanto JSON são formatos de preferência porque apresentam os dados de forma simplificada que facilitam a manipulação por outros aplicativos.


Quais foram as melhorias feitas nas APIs?

Conforme as APIs se transformavam em APIs da web (agora onipresentes), vários esforços foram feitos para facilitar um pouco o design e tornar a implementação mais útil.

Um pouco de SOAP e muito de REST

Como o número de APIs da web aumentou, uma especificação de protocolo foi desenvolvida para ajudar a padronizar a troca de informações: o Simple Object Access Protocol, mais conhecido como SOAP. As APIs projetadas com SOAP usam XML no formato de mensagem e recebem solicitações por HTTP ou SMTP. O SOAP facilita o compartilhamento de informações para os aplicativos executados em ambientes diferentes ou escritos em linguagens diferentes.

Outra especificação é a Representational State Transfer (REST). As APIs da web que aderem às limitações de arquitetura da REST são chamadas de APIs RESTful. A REST é fundamentalmente diferente do SOAP: o SOAP é um protocolo e a REST é um estilo de arquitetura. Isso significa que não há um padrão oficial para APIs RESTful da web. Conforme definido na dissertação de Roy Fielding “Architectural Styles and the Design of Network-based Software Architectures”, as APIs serão RESTful contanto que estejam em conformidade com as seis restrições de orientação de um sistema RESTful:

  • Arquitetura cliente-servidor: a arquitetura REST é composta por clientes, servidores, recursos e lida com recursos por HTTP.

  • Sem monitoração de estado: 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 o cliente e o servidor.

  • Sistema em camadas: as interações entre cliente e servidor podem ser mediadas por camadas adicionais. Essas camadas poderiam oferecer recursos adicionais, como balanceamento de carga, caches compartilhados ou segurança.

  • Código sob demanda (opcional): os servidores podem ampliar a funcionalidade de um cliente com a transferência de código executável.

  • Interface uniforme: essa restrição é essencial para o design de APIs RESTful e inclui 4 facetas:

    • Identificação de recursos nas solicitações: os recursos são identificados nas solicitações e separados das representações retornadas para o cliente.

    • Manipulação de recursos por meio de representações: os clientes recebem arquivos que representam recursos. Essas representações precisam ter informações suficientes para permitir a modificação ou exclusão.

    • Mensagens autodescritivas: cada mensagem retornada para um cliente contém informações suficientes para descrever como ele deve processá-las.

    • Hipermídia como plataforma do estado dos aplicativos: depois de acessar um recurso, o cliente REST pode descobrir todas as outras ações atualmente disponíveis por meio de hiperlinks.

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

SOA ou arquitetura de microsserviços

As duas abordagens de arquitetura que mais usam APIs remotas são a arquitetura orientada a serviços (SOA) e a arquitetura de microsserviços. A SOA, a mais antiga das duas abordagens, começou como um aprimoramento aos aplicativos monolíticos. Enquanto um único aplicativo monolítico faz tudo, algumas funções podem ser fornecidas por aplicativos diferentes levemente acoplados por meio de um padrão de integração, como um barramento de serviços corporativos (ESB).

Embora a SOA seja, na maioria dos aspectos, mais simples que uma arquitetura monolítica, ela carrega o risco de mudanças em cascata por todo o ambiente se as interações entre os componentes não forem claramente compreendidas. Essa complexidade adicional reapresenta alguns dos problemas que a SOA buscava remediar.

As arquiteturas de microsserviços são parecidas com os padrões da SOA na utilização de serviços levemente acoplados. No entanto, eles vão além ao fragmentar arquiteturas tradicionais. Os serviços na arquitetura de microsserviços usam uma estrutura comum do sistema de mensageria, como APIs RESTful. Eles usam as APIs RESTful para se comunicar entre eles sem dificultar as transações de conversão de dados ou as camadas de integração adicionais. O uso de APIs RESTful permite, e até estimula, o fornecimento mais rápido de novos recursos e atualizações. Cada serviço é separado. Um serviço pode ser substituído, aprimorado ou descartado sem afetar nenhum outro serviço na arquitetura. Essa arquitetura leve ajuda a otimizar os serviços distribuídos ou de cloud e oferece suporte à escalabilidade dinâmica para serviços individuais.

APIs and Red Hat

Red Hat gives you modular, lightweight, and comprehensive API solutions that are open source, open standards, and available on-premise or in the cloud.

Platform

Integrate your diverse IT assets with a distributed, flexible integration platform. Red Hat Fuse provides the infrastructure and tooling you need to integrate everything.

Platform

Manage your APIs for internal and external users with a platform that makes APIs easy to share, secure, distribute, control, and monetize.