O que é Web API? E seus principais usos

Para entender o que é uma web API, precisamos dar um passo para trás e entender o que é uma API em si. Segundo a Mozilla Foundation, APIs (Application Programming Interfaces) são construções que permitem que se interaja com uma aplicação através de software. Elas possibilitam conectar diferentes sistemas que podem se utilizar de diferentes linguagens de programação. O que poderia ser uma comunicação impossível ou inviável, encontra um ponto de conexão em comum usando este artefato.

Vejamos em uma contextualização:

Considere que um cliente GoCache queira ter uma integração com a CDN da GoCache para obter dados de tráfego e eventos de segurança, como essa comunicação é possível se ele não tem acesso ao código da CDN GoCache?

Simples, através da API GoCache, que disponibiliza mediante a regras de negócio o acesso a funções, dados e controle da CDN.

O que diferencia uma web API é a comunicação via web, usando principalmente o protocolo HTTP. Com a vida do ser humano cada vez mais cercada por aplicações web e mobile, as web APIs estão se tornando peça chave para grandes transformações na forma como se desenvolve e opera software. A seguir, apresentaremos os principais usos de APIs e os principais padrões em que sua comunicação ocorre.

Quais são os principais usos de Web APIs?

Modernização de arquiteturas de aplicações web

As primeiras aplicações web eram bastante estáticas. As páginas HTML já chegavam do servidor em sua forma final e mesmo que houvesse interatividade via javascript, para atualizar algum conteúdo da página, era necessário que toda sua estrutura fosse enviada novamente pelo servidor. Vamos entrar num acordo que há muito a ser melhorado nessa experiência. E foi justamente o motivo de uma grande evolução introduzida por volta de 2005.

Nessa época foi introduzido o AJAX (Asynchronous Javascript and XML). Essa tecnologia permitia a solicitação assíncrona de dados ao servidor, por meio de javascript e XML, evitando que toda a página tivesse que ser recarregada para atualizar apenas uma pequena parte do conteúdo. Apesar de não serem chamadas por esse nome neste período, pode-se considerar este uso um exemplo de web API. Mais tarde, no fim da década, a introdução dos smartphones trouxe os aplicativos móveis, cuja comunicação com o servidor ocorre de maneira similar ao AJAX.

De lá para cá, novos padrões e frameworks têm surgido, mas podemos agrupar essas tendências em um fenômeno: desacoplamento entre front-end e back-end, no qual os dados são fornecidos assincronamente via API e a página é renderizada ou no navegador, ou em um servidor dedicado para essa função. Desconsiderando outros aspectos, uma das principais vantagens dessa abordagem arquitetural é a agilidade ganha com o menor acoplamento. Quem desenvolve o front-end depende menos de quem trabalha com o back-end para desenvolver e testar novos produtos, e vice-versa. Equipes que definem o design das APIs antes de desenvolver (API First) se beneficiam ainda mais dessa arquitetura agilidade.

Outra característica de arquitetura das primeiras aplicações web é o monolito, ou seja, as aplicações eram majoritariamente constituídas por um bloco homogêneo de código, executado em um único servidor (ou replicado em mais servidores para escala horizontal). Quando se trata de aplicações pequenas, como por exemplo, um blog WordPress, essa abordagem não costuma gerar transtornos, sendo até preferível em grande parte dos casos. Mas quando falamos de aplicações mantidas por dezenas de desenvolvedores ou mais, a situação pode ficar um pouco mais complicada.

Isso começou a ser percebido com mais clareza na época do florescimento das metodologias ágeis e da cultura DevOps. Com dezenas de equipes autônomas trabalhando no mesmo código, é fácil enxergar o potencial que as dependências entre o trabalho delas têm de ser um obstáculo ao desenvolvimento ágil. E como, mesmo o deploy de uma pequena mudança impacta toda a aplicação, a frequência com que novas funcionalidades entram em produção também fica comprometida.

Houveram algumas tentativas de mudar esse cenário, como SOA (Service Oriented Architecture), mas não alcançaram o sucesso. O cenário começou a melhorar com bastante influência da arquitetura de contêineres. Os contêineres fornecem um ambiente muito mais leve, consistente e seguro para quebrar o monolito em dezenas, centenas e até milhares de pequenos serviços, os chamados “microsserviços”. Tecnologias de orquestradores, como Kubernetes, tem auxiliado muito o trabalho de lidar com a complexidade criada por esse tipo de ambiente.

A velocidade desenvolvimento de software cresceu de forma assombrosa nos últimos anos, junto com a difusão dessa arquitetura. E onde entra o papel das APIs? São justamente elas as responsáveis pela comunicação entre os microsserviços. As APIs fornecem uma interface com um nível de abstração suficiente para diminuir o acoplamento entre as diferentes funções da aplicação sem comprometer a coesão do conjunto.

Trocas de valor entre empresas

É praticamente inviável para a maioria dos produtos que todos os seus componentes sejam produzidos pela mesma empresa. Você dificilmente verá um fabricante de celular fazendo seus próprios parafusos, por exemplo. Mas uma coisa que não é tão evidente, é que certas indústrias, como a automotiva e mais recentemente, a aeronáutica, descobriram que podem terceirizar o desenvolvimento e produção de componentes mais complexos e fundamentais para a funcionalidade de seu produto, buscando focar em suas competências chave.

Uma fabricante de aeronaves pode terceirizar o desenvolvimento e produção das asas de seu avião, diminuindo o aporte de capital necessário para desenvolver seu novo produto e podendo concentrar seu foco em aspectos mais globais dele. Mas o que isso tem a ver com APIs? O mesmo fenômeno acontece com a indústria de software e as APIs têm papel importante nisso.

Se voltarmos algumas décadas no tempo, veremos que mesmo nas aplicações web mais antigas, muitos componentes já eram fornecidos por terceiros. Bancos de dados, servidores web e sistemas operacionais seriam muito onerosos se cada empresa que criasse uma aplicação web tivesse que construí-los. E entre 1999 e 2000 houve um grande marco de evolução: a Salesforce surgiu como a primeira empresa que nasceu no modelo de Software como um Serviço (SaaS – Software-as-a-Service). Curiosamente, nesse mesmo ponto surgiu o que é considerado hoje como a primeira web API.

Basicamente, ao invés de oferecer um CD-ROM com um software de CRM a ser instalado nos servidores de seus clientes, a Salesforce trouxe a proposta de entregar a funcionalidade de seu produto via internet. Desse momento em diante, principalmente nos últimos anos, vimos uma explosão de softwares sendo vendidos como serviços. Movimentos como Open Banking e Open Health só acentuam essa tendência.

Hoje, para criar um e-commerce, você não precisa criar seus próprios sistema de pagamentos, helpdesk, mecanismo de recomendação, etc. Tudo isso pode ser fornecido por terceiros, ajudando a focar no que importa, que no caso é garantir uma boa experiência de compra na loja virtual. Como nesse modelo o fornecedor opera seu próprio software, é imperativo que este processe os dados fornecidos por seus clientes. E são justamente as APIs que são a interface de troca de dados entre os dois lados dessa troca de valor.

O conteúdo apresentado nesse post faz parte do nosso Ebook – API Security: Guia para Iniciantes. Faça o download grátis e tenha acesso a um documento com mais de 40 páginas!