REST é bom para todos os contextos na criação de APIs?

O REST foi desenvolvido por Roy Fielding, um dos principais criadores do protocolo HTTP, e tinha por objetivo criar um padrão de comunicação que pudesse utilizar todo potencial que o HTTP oferece, através de recursos como cabeçalhos, verbos e códigos de resposta. Até então, o padrão mais usado era o SOAP, muito criticado por ser considerado “verboso” e “pesado” além do necessário.

Everton Tavares participou do TDC São Paulo 2018 com dois temas: TDD e REST


Mas, apesar do REST ser considerado praticamente o padrão de comunicação atual para criação de APIs, vale nos questionarmos: o REST é bom para todos os contextos? Sabe-se que ele possui diversas limitações, como Over-fetching
(trazer mais informação do que o necessário) e Under-fetching (trazer menos informação que o necessário, obrigando a realização de chamadas adicionais). Devido a isso, surgiram algumas alternativas que valem a pena ser consideradas na hora de definir a API.

 

Alternativas ao REST



GraphQL 


Criado pelo Facebook
Focado em grafos
Permite definir os campos que deseja retornar na consulta
Separa consultas e mutações
Permite mais de uma consulta em uma requisição única
Consulta definida no body de uma mensagem POST
Fortemente tipado

Falcor 

Biblioteca criada pela Netflix
Focada em grafos
Permite definir os campos que deseja retornar na consulta
Somente consultas
Tipagem fraca
Possui diversos tipos de providers
Usar o Falcon é como acessar um JSON diretamente

jrGQL

 

 

Focado em JSON
Permite definir os campos que deseja retornar na consulta
Separa consultas e mutações
Permite mais de uma consulta em uma única requisição
Consulta definida no body de uma mensagem POST
Permite consultas, e também ações como CREATE, UPDATE e DELETE

gRPC

Criado pelo Google
RPC – Remote Procedure Call
Usa Protocol Buffer (biblioteca de serialização)
Usa HTTP/2
Disponível para diversas linguagens (Java, PHP, C++, Go, JavaScript, Ruby, Python, C#, Objective-C, Android/Java e Dart)


Devo criar meu próprio protocolo?



Há situações em que tanto a regra de negócio como a arquitetura da aplicação podem exigir a criação de um protocolo próprio. É o caso do GuiaBolso, que criou um protocolo próprio todo baseado em eventos. “A mensagem às vezes trafega em http, às vezes em filas de serviços, enfim, há várias formas de trafegar mensagens, então eles resolveram criar um protocolo próprio, contendo, por exemplo, informações de autenticação, de qual serviço o usuário quer acessar, de onde veio etc”, comenta o desenvolvedor Everton Tavares. “Em resumo, é uma opção criar o próprio protocolo também, se a sua engine de negócio exigir isso”.

Everton apresentou dois temas no TDC São Paulo: uma palestra intitulada “Minha API deve ser REST?” (slides abaixo), e outra sobre TDD, que você confere no próximo post!

21