gRPC vs. REST

No grande atlas da internet, as interfaces de programação de aplicativos (APIs) são as estradas que conectam cidades, vilas, praias e outros destinos. As APIs permitem que aplicações de software se comuniquem entre si para trocar dados, funcionalidades e recursos. Um relatório da Imperva de 2023 descobriu que cerca de 71% do tráfego da internet consistia em chamadas de API, mostrando o quão vital essa tecnologia é para o funcionamento das aplicações modernas e das empresas.

Não é de se surpreender que entender como construir uma API seja uma habilidade fundamental para a maioria dos desenvolvedores. Mas, como convém a uma infraestrutura tão importante, existem várias variedades.

Para estender nossa metáfora, uma supervia de 12 pistas não é “melhor” do que uma estrada de superfície de pista única; essa supervia destruiria o tecido de um bairro urbano e essa estrada de pista única seria um desastre em uma área de alto tráfego. Diferentes estilos arquitetônicos para construir APIs, como REST e gRPC, funcionam da mesma forma: cada um tem pontos fortes e fracos, e compreender esses pontos fortes e fracos é vital para a criação de uma infraestrutura saudável.

Representational State Transfer, ou REST, é um conjunto de princípios de design (ou restrições arquitetônicas): interface uniforme, desacoplamento cliente-servidor, ausência de estado, capacidade de cache, arquitetura de sistema em camadas e código sob demanda (opcional). As APIs construídas com esses princípios são chamadas de APIs REST ou APIs RESTful.

As APIs REST podem usar várias linguagens de programação e formatos de dados, desde que estejam em conformidade com os princípios REST. É a maneira mais comum de construir uma API.

As APIs REST usam requisições HTTP (também conhecidas como métodos HTTP), como GET, POST, PUT e DELETE, para realizar funções padrão de banco de dados. Essas operações são usadas para criar, ler, atualizar e excluir registros de recursos e são frequentemente chamadas de “CRUD”. Os recursos no lado do servidor são identificados por URLs chamados endpoints.

Por exemplo, uma API REST usaria uma requisição GET para recuperar um registro. Uma requisição POST cria um novo registro. Uma requisição PUT atualiza um registro e uma requisição DELETE exclui um registro. Todos os métodos HTTP podem ser usados em chamadas de API. Uma API REST bem projetada é como um site rodando em um navegador da web com funcionalidade HTTP incorporada.

As informações dos recursos podem ser entregues a um cliente em vários formatos de mensagens, incluindo JavaScript Object Notation (JSON), HTML, XLT, Python, PHP ou texto simples. O JSON é popular porque é legível tanto por humanos quanto por máquinas e é independente de linguagem de programação.

Saiba mais sobre REST vs. GraphQL

Suporte em navegadores: como as APIs REST usam HTTP/1.1 e métodos HTTP padrão, bem como formatos como XML e JSON, elas são compatíveis com navegadores.

Facilidade de uso: devido à sua simplicidade e popularidade, o REST é amplamente considerado mais fácil de entender, especialmente para iniciantes. Ferramentas, tutoriais e guias são abundantes no GitHub e em outros locais.

Flexibilidade: as APIs REST são consideradas de baixo acoplamento entre cliente e servidor. Essa flexibilidade permite mudanças mais simples e rápidas: uma mudança pode ser feita em qualquer um dos lados sem exigir uma mudança no outro.

Ecossistema robusto: as APIs REST têm um número significativo de ferramentas, além de amplo suporte e documentação. A especificação OpenAPI, ou OAS, por exemplo, fornece uma definição padrão do setor para os parâmetros e recursos de uma API REST. A versão mais recente do OAS, OAS 3.1, inclui compatibilidade total com o JSON Schema, identificação padronizada que usa o identificador SPDX e mais.

Dependência do HTTP/1.1: Embora o uso do HTTP/1.1 pelo REST lhe dê suporte universal em navegadores e alguma personalização em cabeçalhos, isso também priva as APIs REST de alguns benefícios do HTTP/2 mais recente. Esses benefícios ausentes incluem streaming bidirecional; o REST oferece suporte apenas a streaming unário, em que uma solicitação é seguida por uma resposta.

Mais lento e menos eficiente: assim como no HTTP/1.1, a dependência do REST em formatos como XML e JSON traz desvantagens, além de benefícios. Esses formatos são legíveis para humanos, o que é positivo, mas também são arquivos relativamente grandes, o que significa transmissão mais lenta.

Requer ferramentas adicionais: o ecossistema do REST pode ser robusto, mas precisa ser, já que alguns recursos não são incorporados à arquitetura. A geração de código, por exemplo, está disponível na forma de plug-ins para REST, mas ainda é um passo extra, com complexidade adicional.

O gRPC é um framework de código aberto que o Google desenvolveu inicialmente como uma implementação específica de chamada de procedimento remoto, ou RPC. Agora é gerenciado pela Cloud Native Computing Foundation (CNCF).

gRPC pode ou não significar “Google Remote Procedure Call”, já que os desenvolvedores brincam dizendo que também pode significar “gRPC Remote Procedure Call” ou várias outras possibilidades. De qualquer forma, o gRPC, como outros RPCs, permite que chamadas remotas pareçam e funcionem como chamadas locais.

Como modelo para interação cliente/servidor, o RPC é frequentemente usado no desenvolvimento de APIs. No modelo RPC, o cliente interage com um intermediário comumente chamado de stub. Esse stub converte os dados para transmissão e, assim que recebe os resultados solicitados do servidor, converte-os de volta para o formato original para o cliente. Existem muitos tipos diferentes de frameworks RPC, incluindo XML-RPC e JSON-RPC.

Esses frameworks RPC são leves, relativamente simples de usar e oferecem benefícios como desenvolvimento simplificado e abstração da comunicação de rede. No entanto, ambientes como arquiteturas de microsserviços e sistemas com grandes cargas de dados geralmente exigem um framework de desempenho mais alto, e o gRPC foi desenvolvido para atender a essa necessidade.

O gRPC usa uma linguagem de definição de interface (IDL) chamada Protocol Buffers (Protobuf) para serializar dados estruturados em binário. Como o binário é mais compacto do que JSON ou XML, isso possibilita a transferência de cargas maiores em velocidades mais rápidas.

O gRPC também usa HTTP/2, o que possibilita streaming bidirecional e faz do gRPC uma forte escolha para APIs em ambientes distribuídos (particularmente os que exigem comunicação em tempo real), arquiteturas de microsserviços, aplicações de streaming e conexão de dispositivos de Internet das coisas (IoT).

Velocidade: o gRPC, por meio do Protobuf, serializa e desserializa dados de várias linguagens, incluindo Java, Python, Ruby e mais, em um payload binário para transmissão. Esse código é leve, portanto, o tempo de transmissão e a latência na troca de dados são reduzidos com as APIs gRPC.

Geração de código: o gRPC inclui um compilador Protobuf chamado [protoc], que oferece recursos nativos de geração de código. Uma vez que a estrutura de dados é definida em um arquivo .proto, o gRPC pode gerar código tanto do lado do cliente quanto do servidor.

Suporte a HTTP/2: ao utilizar o protocolo de transporte HTTP/2, o gRPC suporta vários tipos de streaming. Por exemplo, ele suporta streaming bidirecional, no qual cliente e servidor podem enviar mensagens de forma independente em um fluxo de leitura/escrita, além de streaming do lado do cliente e streaming do lado do servidor.

Interceptores: o gRPC suporta middleware conhecidos como interceptores, que permitem ampliar a funcionalidade. Eles podem ser instalados para implementar segurança, autenticação, análise de métricas e muito mais.

Cancelamento e timeouts: o gRPC suporta cancelamento, também conhecido como timeouts ou deadlines — um tempo especificado após o qual a chamada será cancelada.

Novidade e ecossistema: embora o gRPC inclua recursos extras como geração de código, ele é uma arquitetura relativamente nova, lançada apenas em 2016. Essa novidade deixa a documentação e o suporte limitados em comparação com estilos arquitetônicos mais antigos.

Curva de aprendizado acentuada: alguns desenvolvedores consideram o gRPC mais difícil de aprender em comparação ao REST. Sua serialização de dados em formato binário possibilita uma comunicação eficiente, mas não é legível por humanos.

Falta de suporte em navegadores: como os navegadores da web não suportam nativamente o protocolo gRPC, não é possível chamar diretamente um serviço gRPC a partir de uma aplicação baseada em navegador. Uma forma de contornar essa limitação é usando um proxy como o gRPC-Web, que atua como uma camada de tradução entre o HTTP do navegador e o protocolo gRPC.

REST e gRPC têm muitos elementos em comum e ambos são usados para construir sistemas escaláveis. As semelhanças incluem:

Arquitetura cliente/servidor: gRPC e REST são arquiteturas cliente/servidor com um formato de requisição-resposta que permite ao cliente e ao servidor se comunicarem e trocarem dados. Nessa arquitetura, um cliente envia uma requisição e o servidor responde retornando os dados solicitados ou executando uma ação solicitada.

Independência de plataforma: gRPC e REST permitem que serviços construídos em diferentes plataformas, com diferentes sistemas operacionais, se comuniquem.

Ausência de estado: tanto REST quanto gRPC são considerados stateless, o que significa que cada requisição inclui todas as informações necessárias para ser concluída. O servidor não precisa armazenar informações de requisições anteriores.

Suporte a múltiplas linguagens: ambos os estilos arquitetônicos são independentes em relação à linguagem, o que significa que essas APIs podem ser usadas por aplicações escritas em diversas linguagens de programação. Essa qualidade torna ambos portáteis em diferentes ambientes de programação.

Uso de HTTP: tanto REST quanto gRPC dependem de comunicação baseada em HTTP. No entanto, o gRPC usa HTTP/2, enquanto o REST depende do HTTP/1.1. Além disso, o gRPC abstrai o protocolo de comunicação HTTP/2 subjacente, enquanto no REST a comunicação HTTP é menos abstrata.

As principais diferenças entre REST e gRPC podem ajudar desenvolvedores a decidir qual é a melhor opção para a API que estão construindo. Essas diferenças incluem:

Formato de dados: APIs REST usam principalmente formatos baseados em texto como JSON e XML. O gRPC usa Protobuf para codificar dados em formato binário.

Padrão de comunicação: o REST suporta apenas comunicação unária (uma requisição seguida de uma resposta). O gRPC suporta outros padrões, incluindo streaming bidirecional (cliente e servidor trocam mensagens de forma independente), streaming do servidor (uma única requisição gera múltiplas respostas) e streaming do cliente (múltiplas requisições resultam em uma única resposta).

Padrão de design: o gRPC tem um design orientado a serviços, no qual as operações de servidor que podem ser chamadas são definidas como serviços ou funções. No REST, o design é orientado a recursos, nos quais os métodos HTTP são usados para acessar os recursos do servidor por meio de endpoints definidos por URLs.

Acoplamento: o cliente e o servidor do gRPC são fortemente acoplados, o que significa que o cliente e o servidor devem ter acesso ao mesmo arquivo de protótipo do middleware. Qualquer alteração em um requer alteração no outro. O REST é fracamente acoplado. Essa independência significa que mudanças em um componente não afetam o outro.

Geração de código: o gRPC oferece geração de código integrada; o REST não, embora existam plug-ins disponíveis.

Implementação: o REST não requer software específico e, de fato, tem suporte nativo em navegadores. O gRPC exige software específico tanto do lado do servidor quanto do cliente.

O REST é uma escolha popular de design de API por uma razão: sua simplicidade, ampla compatibilidade e versatilidade o tornam uma excelente opção para muitas aplicações. Para APIs públicas, o REST costuma ser a escolha mais sensata, pois é mais amplamente usado e geralmente mais fácil de entender. Muitos desenvolvedores estão mais familiarizados com REST e podem já ter infraestrutura significativa dedicada especificamente a ele, incluindo servidores, ferramentas de gerenciamento de API, ferramentas de desenvolvimento e diversos recursos de teste.

O REST também oferece suporte a caching embutido, ou seja, a capacidade de armazenar dados acessados com frequência, seja localmente ou por meio de um proxy. O caching pode melhorar significativamente a velocidade e a eficiência, embora precise incluir informações de validação, autenticação e expiração.

O REST também costuma ser preferido para serviços e APIs da web, devido ao seu suporte ao HTTP/1.1 e ao suporte universal em navegadores. Em geral, o REST é preferível ao gRPC para comunicações de dados mais simples. Seu baixo acoplamento e menor complexidade podem melhorar a escalabilidade da arquitetura do sistema e tornar o ambiente mais flexível ao longo do tempo. No entanto, essa adaptabilidade tem um custo em desempenho.

Já o gRPC é uma arquitetura relativamente mais nova, que vem sendo cada vez mais adotada por desenvolvedores devido à sua velocidade, eficiência e ferramentas integradas. Ele é frequentemente usado em aplicações de streaming em tempo real e APIs complexas que exigem alto desempenho e processamento de grandes volumes de dados em sistemas distribuídos. Embora mais complexo que o REST, o uso de HTTP/2 e Protobuf dá ao gRPC maior escalabilidade de desempenho.

O gRPC é especialmente adequado para arquiteturas de microsserviços, já que sua capacidade de transmitir dados bidirecionais em tempo real permite que diferentes serviços de uma aplicação enviem e recebam informações simultaneamente e de forma independente. Ele também vem ganhando espaço em aplicações móveis, por oferecer transmissão de dados rápida e compacta, além do fato de que aplicativos móveis são menos dependentes de navegadores.

O gRPC também é ideal para conectar dispositivos IoT a APIs de back-end, já que suas cargas úteis compactas, baixa latência e alta eficiência de desempenho funcionam muito bem com tecnologias de baixo consumo de energia.