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.

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ê pode conferir neste blog!

Minha API deve ser REST?

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.