Colocar a Web na API da Web

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:

• Explicar duas razões pelas quais os aplicativos Web estão se tornando mais populares.
  
• Declarar usos comuns de APIs da Web.
  
• Entender a economia da API e por que o crescimento da APIs tem sido significativo.
  

APIs em rede podem mudar tudo

As APIs não estão limitadas ao que pode ser encontrado na mesma rede local. Os desenvolvedores e integradores cidadãos também podem consumir APIs oferecidas por sistemas e dispositivos remotos. Elas vão desde conexões privadas, como redes encontradas em empresas com várias filiais e data centers, a redes públicas como a Internet. As chaves para essa rede expansiva são os pontos de extremidade da API.

Pense nos pontos de extremidade como tomadas aos quais os aplicativos consumidores se conectam.

O número e os tipos de dispositivos que podem ser conectados aos soquetes são limitados apenas pela imaginação dos inventores e pela capacidade do utilitário. Da mesma forma, o número de aplicativos que podem aproveitar os dados resumidos pelo ponto de extremidade de uma API é limitado apenas pela imaginação dos desenvolvedores e pela capacidade da infraestrutura do provedor da API.

Caso em questão: Não foi muito tempo depois que o Google ofereceu uma API para o Google Maps que milhares de terceiros desenvolvedores responderam com aplicativos exclusivos e inovadores que consumiram a API, incorporando a funcionalidade de mapeamento do Google diretamente em seus aplicativos. Pense em Yelp, Lyft, Tesla e qualquer outro aplicativo que forneça um mapa com o símbolo de direitos autorais do Google no canto.

É por essa razão que as APIs são frequentemente chamadas de mecanismo de inovação, especialmente para Trailblazers da integração que veem as várias APIs disponíveis para eles como se fossem apenas peças de terceiros usadas para criar novos resultados de negócios e experiências do cliente.

Economia de API

Dependendo do volume de chamadas ou outras formas de dividir diferentes níveis de serviço, um provedor como o Google pode cobrar uma taxa ao desenvolvedor de aplicativos pelo uso da API. Isso dá origem à ideia de uma economia de API.

Agora, o desenvolvedor de aplicativos deve ponderar todos os custos de usar a API em vez de desenvolver a funcionalidade a partir do zero. Ou, como é frequentemente o caso na economia de API, o desenvolvedor pode procurar um provedor mais econômico para serviços semelhantes. O Google Maps, por exemplo, tem vários concorrentes bem conhecidos, incluindo o Here.com.

O crescimento da economia de API é impulsionado por provedores de serviços que competem entre si para lidar com essa necessidade de maior produtividade dos desenvolvedores e de dados comuns. Para cada um dos vários tipos de funcionalidade que podem ser invocados via API (como processamento de cartão de crédito, mapeamento, navegação e tradução), muitas vezes há vários provedores de APIs competindo pela atenção dos desenvolvedores de aplicativos e integradores cidadãos. Por sua vez, à medida que mais recursos são fornecidos na forma de serviços baseados em APIs, a economia de API está acelerando a tendência de um mundo de aplicativos compostos principalmente por APIs prontas para usar. Quanto mais combinável é a solução final, mais flexível é a utilização de novos recursos de outras APIs que elevam o nível em termos de capacidade geral dos negócios.

Crescimento de APIs antes e agora

Você pode estar pensando que APIs em rede são a melhor invenção de todos os tempos. Você também pode estar se perguntando, elas sendo tão boas, por que a indústria de tecnologia não as criou mais cedo? Acontece que elas já tinham sido criadas.

Na época em que o Unix foi lançado, não era incomum que os programadores invocassem remotamente a lógica de negócios de outro computador na rede por meio de tecnologia chamada RPC, ou chamada de procedimento remoto.

Está pronto para uma overdose de acrônimos? Com o tempo, as RPCs cederam lugar a outras formas de solicitações remotas de dados e funcionalidades, como Network DDE (Dynamic Data Exchange), CORBA (Common Object Request Broker Architecture), EDI (Electronic Data Interchange) e outros. Eventualmente, surgiu o chamado XML-RPC (u-huh! RPC novamente!), que mais tarde evoluiu para o que hoje conhecemos como serviços Web, baseados em XML e no protocolo SOAP (Simple Object Access Protocol).

Sempre que uma nova tecnologia de acesso remoto a dados ou funcionalidades surgia, a indústria pensava finalmente ter alcançado a utopia. Mas então vieram as APIs da Web do tipo que estão na moda hoje; aquelas que, como mencionado anteriormente, dependem da funcionalidade que é gerada no protocolo da Web (HTTP) por meio do uso de verbos especiais como GET, PUT e POST. Sim, é o mesmo protocolo da Web que você usa todos os dias para visitar seus sites favoritos.

O (possível) futuro da integração

Assim, se a história puder indicar alguma coisa, a maneira como fazemos a integração entre sistemas pode vir a sofrer mudanças. Existem agora duas tecnologias relativamente novas, semelhantes às da API, que se afastam da abordagem Web em voga atualmente. Uma vem do Facebook, chamada GraphQL, e a outra é do Google, chamada gRPC.

Ambas têm suas próprias vantagens sobre as APIs da Web atuais. Por exemplo, o GraphQL é inspirado pela ideia de um gráfico social e como diferentes itens de dados, como amigos, fotos, locais de trabalho e assim por diante, formam um labirinto de informações inter-relacionadas. O GraphQL torna possível solicitar informações de um gráfico de dados inteiro de uma só vez (em comparação com as várias viagens de ida e volta de solicitações que as APIs tradicionais precisam fazer para realizar a mesma coisa).

Por outro lado, a gRPC tem as suas próprias vantagens. Ela depende do HTTP/2 (versão HTTP 2) que pode transmitir dados bidirecionalmente. Com o HTTP/2, o gRPC pode transformar uma API em uma API de streaming que envia seus dados para o aplicativo consumidor assim que eles ficam disponíveis. Para determinados aplicativos em tempo real, como um ticker do mercado de ações, essa é uma maneira muito mais eficiente de obter dados do que forçar o aplicativo a verificar constantemente se há novos dados disponíveis, como as APIs tradicionais fazem.

Mesma ideia, outra tecnologia

Seja o protocolo da Web, GraphQL, gRPC ou alguma abordagem que ainda será inventada para as APIs, no fundo, a ideia das APIs em rede é realmente transformar um recurso de negócios em um serviço em rede que outros aplicativos podem tratar remotamente como uma peça terceirizada da experiência do cliente. À medida que o inventário de peças terceirizadas (a economia da API) aumenta, também aumenta sua oportunidade de superar a concorrência com inovações e experiências que seriam difíceis de alcançar com tudo produzido internamente.

A oportunidade também funciona na outra direção. Quais competências comerciais sua organização deve oferecer a ela própria e aos desenvolvedores externos como um serviço em rede na forma de uma API? Literalmente, essa é a pergunta que vale milhões de dólares, especialmente para aqueles que desejam se tornar Trailblazers da integração!