API • Out 19, 2017
Ao mesmo tempo, o advento do RESTFULL nos libertou do "jardim murado" das tecnologias proprietárias, permitindo que utilizássemos a melhor tecnologia para um determinado fim, o que fez "florescer" a utilização de bancos de dados não relacionais, por exemplo. A solução simples utilizada pelo REST foi utilizar um protocolo verdadeiramente universal - o HTTP - e um modelo de organização lógica que é intuitivo e rápido de entender.
Mas o REST já começou a demonstrar a sua idade, na medida em que é cada vez maior o número de dispositivos e sistemas que precisam consumir e gravar dados através de APIs. Um dos problemas mais comuns é a necessidade de executar múltiplas chamadas a API para ter acesso a todos os dados que são necessários para uma tarefa específica. Leve em consideração o seguinte exemplo:
uma chamada a user/:id retorna os dados relativos ao usuário id como nome, email, idade, etc.;
uma chamada a user/:id/friends trás a lista com os nomes e ids de todos os amigos conectados ao usuário :id
Se eu por acaso quiser saber a média de idade dos amigos de um determinado usuário, precisarei fazer 1 chamada para buscar a listagem de amigos deste e mais 1 chamada para cada amigo nesta lista. A não ser que seja disponibilizada uma rota para este fim. É aí então que surgem as v1, v2, v3, etc... No mínimo, deveria haver uma forma mais fácil de fazer algo do tipo.
Projetos como o Falcor e GraphQL, lançados como software livre por Netflix e Facebook, respectivamente, tem como objetivo resolver justamente este e outros problemas de acesso remoto a dados através de APIs.
Em ambos os casos trata-se de um serviço que se conecta diretamente a uma ou mais fontes de dados, gerando um grafo e possibilitando que uma determinada requisição, solicite ao servidor apenas os dados dos quais ela necessita.
Dentre outros cenários, projetos como esses parecem muito úteis no ambiente de microsserviços. Imagine o cenário onde há um cliente web e diferentes clientes mobile. Cada um deles precisa de uma versão levemente diferente dos dados para conseguir compôr a interface que será apresentada para o usuário. Como cada cliente solicita ao servidor exatamente aquilo que precisa, fica muito mais fácil manter e evoluir a API mesmo que as necessidades mudem no futuro e sem que seja necessário fazer uso de versionamento.