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.

TDC São Paulo 2018: 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!

Minha api deve ser rest? de ezidiu

 

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



Serviços e Plataformas Cloud


Com entrega de consultoria baseada nos principais métodos e práticas de mercado, os Especialistas Mandic Cloud evidenciam e aceleram os resultados e impacto de transformação da área de tecnologia nas empresas com planejamento, implantação/migração e sustentação de workloads com gerenciamento na nuvem com o uso de automação, melhores práticas em DevOps e Data Analytics (Engenharia de Dados) para a Transformação Digital de negócios nas principais plataformas de cloud do mercado:
Gestão AWS Brasil

com Especialistas certificados para te acompanhar de perto, em português. Amazon AWS

Virtualização de Servidores VMware

e Especialistas Mandic Cloud 24x7 que simplificam sua vida. VMware

Orquestração Cloud OpenStack

com Especialistas Full-stack para conectar sua empresa ao futuro. OpenStack Cloud

Microsoft Azure Cloud

e Especialistas em Clouds acelerando o acesso do seu negócio à nuvem corporativa. Microsoft Azure

Google Cloud Platform

e Especialistas DevOps construindo o futuro com Transformação Digital. Google Cloud Platform