API, Uma Viagem no Tempo e a Perspetiva de Futuro
O que foram com a Web 1.0 e poderão vir a ser com a Web 3.0
As “Application Programming Interfaces”, mais conhecidas como APIs, existem desde os primórdios da computação. Felizmente desde o início dos anos 2000, as APIs da web moderna passaram a tomar uma função mais específica de fornecimento de informação, de uma forma mais simpática e agora de fácil implementação e consumo.
Este artigo pretende não só olhar para o passado e perceber o que foram as APIs, mas também ter uma perspetiva do que podem ser num futuro próximo e quais são as potencialidades desta tecnologia web para a nova Web 3.0.
APIs, O Que Eram e o Que Serão
Começando pelo 101 das APIs, estas representam uma interface que age entre diferentes tipos de software, facilitando a interação entre humanos e o próprio computador. O grande objetivo das APIs é fornecer informação e serviços a terceiros.
Pensa num website, a sua função base não é muito diferente, ele fornece-te informação de uma forma mais bonita e arrojada. Por outro lado, as APIs, prestam-te a mesma função sem todos os floreados necessários para a boa legibilidade e experiência humana, mas sim com a informação em dados brutos. Isto não invalida que não se tenha de pensar na construção destas APIs de forma coerente, legível e percetível, pelo contrário, é necessário estabelecer padrões e aplicar-se boas práticas para que qualquer pessoa externa ao funcionamento da nossa API possa entender como este sistema funciona. Para isso é necessário ter em atenção a uma completa, organizada, clara e bem formatada documentação.
Este conceito abstrato de API como um ponto de acesso programável que invoca uma outra aplicação apesar de rudimentar, foi transformando-se e evoluindo ao longo dos anos.
No início as APIs serviam um propósito para o e-commerce onde a Amazon, a Salesforce e o eBay reinavam. Tudo começou com a Salesforce, uma das primeiras empresas a conseguir perceber o potencial da gestão de dados através de uma API. Isto aconteceu em 1990 quando criou a sua ferramenta automatizada de vendas, que marcou o início dos softwares existentes como um serviço.
Mais tarde, na chegada da segunda geração da web, a Web 2.0, as aplicações começaram a ser baseadas no conceito de rede social e num ambiente online mais dinâmico onde o utilizador é um prosumer, ele tem agora a possibilidade de criar do seu próprio conteúdo. Foi neste preciso momento que houve uma mudança de como as APIs eram encaradas.
SOAP APIs (ainda antes do REST)
Antes das REST APIs, existiam as SOAP APIs (Simple Object Access Protocol). Estas possuíam as vantagens de realizar um transporte independente por não requerer o uso de HTTP e de realizar a troca de informações estruturadas em plataformas descentralizadas e distribuídas, enquanto que as APIs REST funcionam através de uma comunicação ponto a ponto. Sendo que as mesmas dependiam muito da linguagem XML.
REST APIs
A partir daí nasceu o conceito de REST (Representational State Transfer) aliado às APIs, visto que houve uma necessidade de existir uma evolução dos paradigmas processuais anteriores para outros orientados a objetos. Esta necessidade originou um novo estilo de arquitetura de software construída a partir de endpoints, os pontos de comunicação e acesso para uma aplicação.
Nesta arquitetura, a informação exigida pelo consumidor (request) é lidada pelo fornecedor, a API que de seguida dá uma resposta (response). Pensemos em duas pessoas a conversar e uma delas questiona uma pergunta direta. A pessoa a quem nos questionamos irá responder logo em seguida, retornando a informação que a pessoa que colocou a pergunta estava à procura.
Apesar de ter levado algum tempo até toda a comunidade de pessoas da área tecnológica perceber que as REST APIs podiam inovar no mundo tecnológico, a comunidade desenvolvedora para a web percebeu de imediato a sua importância para a implementação na web e adotou-a sem demoras. Assim sendo, através das diretrizes REST e das quatro operações básicas CRUD (Create, Read, Update e Delete) com os seus correspondentes tipos de HTTP requests (os pedidos feitos no nosso browser à nossa API), que são do tipo POST, GET, PUT e DELETE, começou a aderir-se ao uso das REST APIs.
A partir deste momento de viragem, surgiram as APIs públicas que permitiram que as plataformas pudessem invocar outras APIs na sua aplicação através de uma interface programável. Algo a ter em atenção nestas APIs públicas que podem ser acessíveis por qualquer pessoa, é a sua documentação. É considerável que à semelhança da finalidade de uma linguagem de programação, como é o exemplo do React em que é abstraída a complexidade através da exposição de uma interface legível para o ser humano, que se faça os mesmo para as APIs de modo a serem digeridas de uma forma mais clara por um programador que a esta a desenvolver.
Twitter API — The Game Changer
Foi também no começo desta adesão ao conceito das APIs por volta de 2006 que o Twitter cria a sua própria API para satisfazer as necessidades dos desenvolvedores web, que já à época criavam aplicações externas com base na tecnologia do Twitter. Numa primeira fase, para o seu uso, bastava um username e uma password de modo a se aceder à plataforma e assim os programadores conseguiam ter acesso a todo o tipo de tweets e conteúdo produzido no Twitter. Com o tempo esta ideia foi se desmurando e o Twitter adicionou entraves ao livre e facilitado acesso a estes dados, exigindo numa primeira fase sistemas de OAuth e mais tarde um sistema de autenticação por token, limitando assim, o acesso a estes dados, de modo a poder minimizar o tráfico gerado por aplicações de terceiros que usavam a API do Twitter e adicionar uma maior camada de segurança.
Ainda assim, este foi um momento importante para a comunidade desenvolvedora para a web, visto que esta API permitiu não só aos programadores terem acesso a esta informação, mas foi também a partir dela que em conjunto acabaram por criar novas funcionalidades para a própria plataforma do Twitter, como foi o caso das hashtags e do botão de retweet. É interessante perceber como a exposição livre de informação sobre uma plataforma pode mais tarde beneficiar e criar novo valor à aplicação a partir do interesse gerado por uma comunidade de pessoas que a usam e estão interessados em que possua novas funcionalidades que satisfaçam as suas necessidades, sendo os próprios idealizá-las ou até criá-las.
Acabamos de ver o exemplo das REST APIs, onde temos um paradigma pedido-resposta em que a interação do consumidor com a API implica que haja sempre um pedido inicial pelo consumidor. E se este consumidor quisesse perguntar algo mais complexo que implica mais do que uma resposta ou mais do que uma ação? É nesta linha de pensamento que podemos olhar para o que poderá ser o futuro das APIs e o que elas prometem com a chegada da Web 3.0.
Web 3.0 — APIs Orientadas a Eventos
Nesta terceira geração da web teremos aplicações web hiperinterativas onde o ser humano pode colaborar com as máquinas em tempo real, que poderá muito possivelmente ser suportada pela tecnologia Blockchain, que promete ser uma tecnologia mais descentralizada, digna de maior confiança devido à maior privacidade e uma maior virtualização, onde o poder irá pertencer às massas e não às corporações gananciosas existentes.
Dado sermos todos seres consumidores de informação, gostamos de perceber o que está acontecer em tempo real, sem que façamos qualquer tipo de ação ou nos incomodemos com um chato refresh. Para colmatar isto, surgiu uma nova forma de ver as APIs nesta nova era da web com as promissoras event-driven APIs. O que quer dizer isto de “event-driven”? Ora o que o próprio nome indica. São APIs que estão envolvidas na interação existente e que subscrevem um certo evento gerado que irá agir adequadamente dependo do seu tipo.
Ou seja, é o backend que notifica o cliente quando algo de interessante acontece. Ao contrário das REST APIs (unidirecionais, síncronas e onde o utilizador “puxa” a informação) este tipo de APIs são assíncronas e mantêm-se a enviar a informação para o cliente.
Para ser mais fácil de compreender este conceito, vamos olhar para um exemplo da vida real:
Neste exemplo temos uma pessoa que diz a outra para lhe dizer quando irá sair de casa. A outra responde-lhe afirmativamente e após sair de casa envia-lhe a informação esperada que de que facto já saiu de casa. Posto isto em termos mais técnicos, após o consumer subscrever a um certo evento, o fornecedor (API) inicia-o. Depois disso o cliente define um endpoint para que o fornecedor o possa chamar de modo a enviar a notificação desejada ao consumidor.
Existem vários tipos de tecnologias a considerar quando falamos de event driven APIs como os Webhooks, Websockets, Server-sent Events e também Streaming. É uma questão de se escolher qual é a mais apropriada para cada tipo de situação, dependendo muito da direcionalidade que queremos com que a informação flua para o servidor.
APIs e o Futuro
“ Personal data is the new oil of the internet and the new currency of the digital world. “ — Meglena Kuneva, European Consumer Commissioner, 2009
Nesta fase evolutiva da web o valor atribuído a estes dados pessoais é gigantesco, é assim importante entender que os nossos dados pessoais acabam por ser a nossa moeda para podermos viver no mundo atual cada vez mais digital. Se fizermos uma analogia dos dados serem o novo petróleo da internet. As APIs são os oleodutos que o conduzem e o backend das APIs a refinaria que trata do modo como estes dados são retornados.
Para o futuro das APIs e com a chegada da Web 3.0 podemos esperar modelos de negócio construídos tendo em conta as APIs orientadas a eventos, uma melhor experiência quanto às APIs em dispositivos móveis com a chegada do HTTP3, uma maior estandardização para as APIs serem vistas como ainda maiores autoestradas de informação para as grandes empresas corporativas.
Reflexão Final
Em suma, a evolução da web quase que cresce proporcionalmente comparando com o modo como as APIs se desenvolvem ao longo dos anos. Uma vez que estas estão na base do modo como as aplicações web funcionam atualmente. Há assim um crescimento exponencial daquilo que é a tecnologia das APIs e o que estas podem resolver tendo em conta não só os programadores mas também o utilizador final.
Existe ainda um futuro pela frente para as APIs e este intermediário apresenta cada vez mais importância tendo em conta os avanços nos aspetos tecnológicos ao longo do tempo que sempre tentaram e continuam a tentar cumprir com as necessidades do utilizador.
