REST vs gRPC: como comunicar os seus serviços?

Quando os sistemas crescem e se dividem em serviços, surge a pergunta de como devem comunicar entre si. Duas opções destacam-se: REST, o padrão universal baseado em HTTP, e gRPC, um protocolo moderno de alto desempenho criado pela Google. Não competem exatamente no mesmo terreno: REST brilha nas APIs públicas e na comunicação com navegadores, enquanto gRPC se destaca na comunicação interna entre serviços. Perceber quando usar cada um evita decisões que penalizam o desempenho ou a compatibilidade.

Neste artigo comparamos REST e gRPC, as suas forças e os seus limites, e explicamos quando convém cada um.

O que é REST

REST é um estilo de API baseado em HTTP no qual se opera sobre recursos através dos métodos padrão, trocando dados normalmente em formato JSON. A sua grande vantagem é a universalidade e a simplicidade: é entendido por qualquer cliente, incluindo o navegador, é legível por humanos, fácil de depurar e conta com um ecossistema enorme. É a opção por omissão para APIs públicas, integrações com terceiros e qualquer comunicação onde a compatibilidade e a facilidade de uso importem mais do que o desempenho extremo.

O que é gRPC

gRPC é um protocolo de comunicação de alto desempenho que usa HTTP/2 e troca dados num formato binário compacto (Protocol Buffers) em vez de texto. A sua vantagem é a velocidade e a eficiência: as mensagens binárias são muito mais leves e rápidas do que o JSON, suporta streaming bidirecional e gera automaticamente o código cliente e servidor a partir de um contrato. Brilha na comunicação interna entre microsserviços, onde o desempenho e a baixa latência são críticos e ambos os extremos estão sob o seu controlo.

As diferenças-chave

Estes são os fatores onde mais se nota a diferença entre REST e gRPC:

• Formato: texto (JSON) em REST; binário (Protocol Buffers) em gRPC.
• Desempenho: maior em gRPC; suficiente em REST.
• Compatibilidade: REST funciona em todo o lado; gRPC tem limites no navegador.
• Legibilidade: REST é legível; gRPC não, por ser binário.
• Streaming: nativo e potente em gRPC; limitado em REST.
• Contrato: estrito e autogerado em gRPC; mais livre em REST.

O fator do navegador

Uma diferença decisiva é a compatibilidade com o navegador. REST funciona de forma nativa a partir de qualquer aplicação web, o que o torna imprescindível para as APIs que um frontend consome. gRPC, por outro lado, não funciona diretamente a partir do navegador sem uma camada intermédia, pelo que o seu terreno natural é a comunicação servidor a servidor. Esta limitação, mais do que um defeito, define onde cada um encaixa: REST de frente para o exterior, gRPC no interior do sistema.

Contrato e manutenção

Outra diferença prática está em como se define e se mantém a comunicação. gRPC parte de um contrato explícito (o ficheiro de Protocol Buffers) a partir do qual se gera automaticamente o código de cliente e servidor, o que reduz erros e mantém ambos os extremos sincronizados: se o contrato muda, as duas partes atualizam-se de forma coerente. REST, por ser mais livre, oferece mais flexibilidade mas deixa nas mãos da equipa a disciplina de documentar e versionar bem a API para que os clientes não se quebrem. Para sistemas internos que evoluem depressa e onde controla ambos os lados, o contrato estrito do gRPC é uma vantagem de manutenção; para APIs públicas com muitos consumidores externos, a flexibilidade e a tolerância do REST costumam pesar mais.

Quando escolher cada um

Escolha REST para APIs públicas, integrações com terceiros e toda a comunicação que deva ser consumida por um navegador ou por um cliente que não controla: ganha em compatibilidade e simplicidade. Escolha gRPC para a comunicação interna entre microsserviços de alto desempenho, onde controla ambos os extremos e a velocidade e a eficiência são críticas. Muitos sistemas usam ambos: REST na fronteira de frente para o cliente e gRPC entre os serviços internos. A chave é usar cada um no seu terreno natural.

Na AxiomTech desenhamos a comunicação entre os seus sistemas com o protocolo adequado, REST ou gRPC, consoante o desempenho e a compatibilidade. Se está a definir a arquitetura dos seus serviços e hesita sobre como os ligar, falemos e aconselhamo-lo consoante o seu caso.