Qual é a diferença entre gRPC e REST?
gRPC e REST são duas formas de criar uma API. Uma API é um mecanismo que permite que dois componentes de software se comuniquem usando um conjunto de definições e protocolos. No gRPC, um componente (o cliente) chama ou invoca funções específicas em outro componente de software (o servidor). Na REST, em vez de chamar funções, o cliente solicita ou atualiza os dados no servidor.
O que é gRPC?
O que é RPC?
Na RPC, as comunicações cliente-servidor funcionam como se as solicitações da API do cliente fossem uma operação local ou como se a solicitação fosse um código interno do servidor.
Na RPC, um cliente envia uma solicitação para um processo no servidor que está sempre ouvindo chamadas remotas. Na solicitação, ele contém a função do servidor a ser chamada, junto com todos os parâmetros a serem transmitidos. Uma API RPC usa um protocolo como HTTP, TCP ou UDP como o mecanismo subjacente de troca de dados.
Como a gRPC é diferente da RPC?
A gRPC é um sistema que implementa a RPC tradicional com algumas otimizações. Por exemplo, o gRPC usa buffers de protocolo e HTTP 2 para a transmissão de dados.
Ele também abstrai o mecanismo de troca de dados do desenvolvedor. Por exemplo, outra implementação da API RPC muito usada, a OpenAPI, exige que os desenvolvedores mapeiem os conceitos de RPC para o protocolo HTTP. Mas o gRPC abstrai a comunicação HTTP subjacente. Essas otimizações tornam o gRPC mais rápido, fácil de implementar e mais compatível com a Web do que outras implementações de RPC.
O que é REST?
REST é uma abordagem de arquitetura de software que define um conjunto de regras para trocar dados entre componentes de software. Ele é baseado em HTTP, o protocolo de comunicação padrão da Web. As APIs RESTful gerenciam as comunicações entre um cliente e um servidor por meio de verbos HTTP, como POST, GET, PUT e DELETE para operações de criação, leitura, atualização e exclusão. O recurso do lado do servidor é identificado por uma URL conhecida como endpoint.
A REST funciona da seguinte maneira:
- O cliente faz uma solicitação para criar, modificar ou excluir um recurso no servidor
- A solicitação contém o endpoint do recurso e também pode incluir parâmetros adicionais
- O servidor responde, devolvendo todo o recurso ao cliente quando a operação for concluída
- A resposta contém dados no formato JSON e códigos de status
As APIs criadas usando orientações REST são chamadas de APIs RESTful ou APIs REST.
Por que as organizações usam gRPC e REST?
gRPC e REST são duas abordagens diferentes para o desenvolvimento de APIs.
Uma API funciona de forma semelhante a um pedido de comida em um restaurante por meio de um menu. Em qualquer restaurante, um cliente (cliente) pode pedir comida do menu (API), que tem um conjunto fixo de pratos. Isso é comunicado à cozinha (servidor) que prepara o prato solicitado e o envia ao cliente. O cliente não precisa saber como a cozinha preparou o pedido, apenas o que esperar em retorno. A padronização dos formatos de menu significa que os clientes e as cozinhas sabem como usá-los.
Sem APIs, não haveria um acordo compartilhado sobre como diferentes aplicações ou serviços de software se comunicam. Programadores de duas aplicações separadas precisariam falar um com o outro para determinar como desenvolver a troca de dados todas as vezes.
Existem diferentes tipos de arquiteturas de API, como gRPC e REST, pois arquiteturas diferentes podem ser melhores para diferentes casos de uso em uma organização. Um designer de API deve escolher sua arquitetura cliente-servidor preferida com base nos requisitos do sistema.
Quais são as semelhanças entre a gRPC e a REST?
REST e gRPC compartilham algumas semelhanças inatas com as abordagens arquitetônicas da API.
Mecanismo de troca de dados
Ambos permitem que dois componentes de software, um cliente e um servidor, se comuniquem e troquem dados com base em um conjunto compartilhado de regras. Essas regras se aplicam independentemente de como cada componente de software opera internamente.
Comunicação baseada em HTTP
Ambos transmitem dados por meio do mecanismo HTTP de solicitação-resposta, o protocolo de comunicação eficiente preferido da Web. No entanto, na gRPC, isso está oculto para o desenvolvedor, enquanto na REST é mais aparente.
Flexibilidade de implementação
Você pode implementar REST e gRPC em uma ampla variedade de linguagens de programação. Essa qualidade os torna altamente portáteis em todos os ambientes de programação. Isso leva a uma interoperabilidade ideal com suporte quase universal.
Adequação para sistemas distribuídos e escaláveis
Tanto a gRPC quanto a REST usam o seguinte:
- Comunicação assíncrona, para que o cliente e o servidor possam se comunicar sem interromper as operações
- Design sem estado, para que o servidor não precise se lembrar do estado do cliente
Isso significa que os desenvolvedores podem usar gRPC e REST para criar sistemas resistentes a falhas com um grande número de solicitações simultâneas. Você pode criar sistemas distribuídos e escaláveis com vários clientes.
Princípios da arquitetura: gRPC versus REST
Embora REST e gRPC ofereçam uma função semelhante, os modelos subjacentes diferem significativamente em sua arquitetura.
Modelo de comunicação
Usando uma API REST, um cliente envia uma única solicitação da API REST para um servidor, e o servidor então retorna uma única resposta. O cliente deve esperar que o servidor responda antes de continuar as operações. Esse mecanismo é um modelo de solicitação-resposta e é uma conexão de dados unária (um para um).
Por outro lado, com o gRPC, um cliente pode enviar uma ou várias solicitações de API ao servidor, o que pode resultar em uma ou várias respostas do servidor. As conexões de dados podem ser unárias (um para um), streaming de servidor (um para muitos), streaming de cliente (muitos para um) ou streaming bidirecional (muitos para muitos). Esse mecanismo é um modelo de comunicação de resposta do cliente e é possível porque o gRPC é baseado em HTTP 2.
Operações que podem ser chamadas no servidor
Em uma API gRPC, as operações de servidor que podem ser chamadas são definidas por serviços, também conhecidos como funções ou procedimentos. O cliente gRPC invoca essas funções da mesma forma como você chamaria uma função internamente em uma aplicação. Isso é conhecido como design orientado a serviços. Veja abaixo um exemplo:
createNewOrder(customer_id, item_id, item_quantity) -> order_id
Na REST, há um conjunto limitado de verbos de solicitação HTTP que o cliente pode usar em recursos do servidor definidos por uma URL. O cliente chama o próprio recurso. Isso é conhecido como design orientado a entidades. O design orientado a entidades se alinha bem com os métodos de programação orientados a objetos. Veja abaixo um exemplo:
POST /pedidos <headers> (customer_id, item_id, item_quantity) -> order_id
Embora você possa projetar APIs gRPC em uma abordagem orientada a entidades, isso não é uma restrição do próprio sistema.
Formato de troca de dados
Com uma API REST, as estruturas de dados passadas entre os componentes do software geralmente são expressas no formato de troca de dados JSON. É possível passar outros formatos de dados, como XML e HTML. O JSON é flexível e fácil de ler, embora deva ser serializado e traduzido para uma linguagem de programação.
Por outro lado, o gRPC usa o formato Protocol Buffers (Protobuf) por padrão, embora também ofereça suporte nativo a JSON. O servidor define uma estrutura de dados usando a linguagem de descrição da interface (IDL) do Protocol Buffer em um arquivo de proto-especificação. O gRPC então serializa a estrutura em formato binário e a desserializa para qualquer linguagem de programação especificada. Esse mecanismo o torna mais rápido do que usar o JSON, que não é compactado durante a transmissão. Os buffers de protocolo não são legíveis por humanos, ao contrário de uma API REST usada com JSON.
Outras diferenças importantes: gRPC versus REST
Outras diferenças importantes: gRPC versus REST
Além do estilo arquitetônico, a gRPC e a REST têm outras diferenças inerentes.
Acoplamento cliente-servidor
A REST é frouxamente acoplada, o que significa que o cliente e o servidor não precisam saber nada sobre a implementação um do outro. Esse acoplamento fraco facilita a evolução da API ao longo do tempo. Isso ocorre porque uma alteração nas definições do servidor não exige necessariamente uma alteração no código do cliente.
O gRPC é fortemente acoplado, o que significa que o cliente e o servidor devem ter acesso ao mesmo arquivo proto. Qualquer atualização no arquivo exige atualizações no servidor e no cliente.
Geração de código
O gRPC oferece uma seleção integrada de recursos de geração de código nativo do lado do cliente e do lado do servidor. Eles estão disponíveis em vários idiomas devido ao protoc, o compilador Protocol Buffers. Depois de definir a estrutura no arquivo proto, o gRPC gera o código do lado do cliente e do lado do servidor. A geração de código torna o desenvolvimento de APIs menos demorado.
Por outro lado, a REST não oferece nenhum mecanismo integrado de geração de código, portanto, os desenvolvedores devem usar ferramentas adicionais de terceiros se precisarem desse recurso. Saiba mais detalhes sobre a geração de código.
Streaming bidirecional
O gRPC oferece comunicação de streaming bidirecional. Isso significa que tanto o cliente quanto o servidor podem enviar e receber várias solicitações e respostas simultaneamente em uma única conexão.
A REST não oferece esse recurso.
Quando usar o gRPC versus REST
Atualmente, a REST é a arquitetura de API mais popular para serviços Web e arquiteturas de microsserviços. A popularidade da REST se deve à sua implementação simples e ao mapeamento, legibilidade e flexibilidade da estrutura de dados. É fácil para novos programadores começarem a desenvolver APIs RESTful para suas aplicações, seja para desenvolvimento de serviços Web ou microsserviços internos.
Aqui estão os casos de uso de uma API REST:
- Arquiteturas baseadas na Web
- APIs voltadas para o público para facilitar a compreensão por usuários externos
- Comunicações de dados simples
A gRPC, diferentemente da REST, foi projetada especificamente para permitir que os desenvolvedores criem APIs de alta performance para arquiteturas de microsserviços em datacenters distribuídos. É mais adequado para sistemas internos que exigem streaming em tempo real e grandes cargas de dados. O gRPC também é uma boa opção para arquiteturas de microsserviços compostas por várias linguagens de programação, quando for improvável que a API mude com o tempo.
Uma API gRPC é melhor para estes casos de uso:
- Sistemas seguros e de alta performance
- Altas cargas de dados
- Aplicações em tempo real ou de streaming
Uma nota sobre o desenvolvimento de software na Web
Embora o HTTP seja o principal protocolo da Web, existem diferentes versões do HTTP com vários graus de adoção em navegadores e servidores Web.
Uma API gRPC sempre usa HTTP 2, e uma API REST normalmente usa HTTP 1.1, que não é o mesmo protocolo HTTP. Embora o HTTP 2 agora seja um protocolo Web comum, ele não tem suporte universal para navegadores, ao contrário do HTTP 1.1. Esse suporte limitado ao navegador pode tornar o gRPC uma opção menos atraente para desenvolvedores que desejam oferecer suporte a aplicações Web.
Resumo das diferenças: gRPC versus REST
| gRPC API |
API REST |
|
| O que é isso? |
Um sistema para criar e usar APIs com base no modelo de comunicação cliente-servidor da Chamada de Procedimento Remoto (RPC). |
Um conjunto de regras que define a troca estruturada de dados entre um cliente e um servidor. |
| Abordagem de projeto |
Design orientado a serviços. O cliente solicita que o servidor execute um serviço ou uma função que pode ou não afetar os recursos do servidor. |
Design orientado a entidades. O cliente solicita que o servidor crie, compartilhe ou modifique recursos. |
| Modelo de comunicação |
Várias opções como unário, um servidor para vários clientes, um cliente para vários servidores e muitos clientes para vários servidores. |
Unário. Um único cliente se comunica com um único servidor. |
| Implementação |
Requer o software gRPC no lado do cliente e do servidor para operar. |
Você pode implementá-lo no lado do cliente e do servidor em uma ampla variedade de formatos sem a necessidade de um software comum. |
| Acesso aos dados |
Chamadas de serviço (função). |
Vários endpoints na forma de URLs para definir recursos. |
| Dados retornados |
No tipo de retorno fixo do serviço, conforme definido no arquivo Protocol Buffer. |
Em uma estrutura fixa (normalmente JSON), definida pelo servidor. |
| Acoplamento cliente-servidor |
Firmemente acoplado. Tanto o cliente quanto o servidor precisam do mesmo arquivo de buffer de protocolo que define o formato dos dados. |
Frouxamente acoplado. O cliente e o servidor não estão cientes dos detalhes internos. |
| Geração automática de código |
Recurso integrado. |
Requer ferramentas de terceiros. |
| Streaming bidirecional |
Presente. |
Não está presente. |
| Mais adequada para |
Arquiteturas de microsserviços de alta performance ou com muitos dados. |
Fontes de dados simples, nas quais os recursos são bem definidos. |
Como a AWS oferece suporte aos requisitos de gRPC e REST?
A Amazon Web Services (AWS) tem uma variedade de serviços e ferramentas para ajudar os designers de API a criar, executar e gerenciar aplicações e serviços modernos baseados em APIs. Para obter mais informações, leia sobre o desenvolvimento de aplicações modernas na AWS.
Aqui estão alguns exemplos de ofertas da AWS que podem oferecer suporte aos seus requisitos de API:
- O Amazon API Gateway permite que os desenvolvedores criem, publiquem e gerenciem APIs em grande escala. Com o API Gateway, você pode criar APIs RESTful otimizadas para arquiteturas de microsserviços em contêineres e aplicações Web.
- O Elastic Load Balancing (ELB) distribui o tráfego de rede para melhorar a escalabilidade da aplicação. Ele pode direcionar e balancear a carga do tráfego gRPC entre microsserviços ou entre clientes e serviços habilitados para gRPC. Isso facilitará para os clientes a introdução do gerenciamento do tráfego gRPC em suas arquiteturas, sem alterar nenhuma infraestrutura subjacente em seus clientes ou serviços.
- O Amazon Virtual Private Cloud (Amazon VPC) Lattice é um serviço de rede de aplicações que conecta, monitora e protege consistentemente as comunicações entre os serviços. Escale os recursos de computação e rede automaticamente para suportar workloads HTTP, HTTPS e gRPC de alta largura de banda.
Comece a usar a gRPC e a REST na AWS criando uma conta hoje mesmo.
