Qual é a diferença entre RPC e REST?
Chamada de procedimento remoto (RPC) e REST são dois estilos arquitetônicos no design de APIs. APIs são mecanismos que permitem que dois componentes de software se comuniquem usando um conjunto de definições e protocolos. Os desenvolvedores de software usam componentes desenvolvidos anteriormente ou de terceiros para executar funções, para que não precisem escrever tudo do zero. As APIs RPC permitem que os desenvolvedores chamem funções remotas em servidores externos como se fossem locais para o software. Por exemplo, você pode adicionar a funcionalidade de chat à aplicação chamando remotamente as funções de mensagens em outra aplicação de chat. Por outro lado, as APIs REST permitem que você realize operações de dados específicas em um servidor remoto. Por exemplo, a aplicação pode inserir ou modificar os dados de funcionários em um servidor remoto usando APIs REST.
Quais são as semelhanças entre a RPC e a REST?
A Chamada de Procedimento Remoto (RPC) e a REST são formas de criar APIs. As APIs são essenciais na criação de sites modernos e em outros sistemas distribuídos. Eles permitem que duas aplicações ou serviços separados e distribuídos se comuniquem sem conhecer os detalhes internos de como o outro funciona. Essas duas aplicações ou serviços podem não ter nada em comum um com o outro, exceto por uma pequena troca de dados.
As APIs também são um mecanismo comum para o back-end de um programa (o componente lógico) se comunicar com o front-end de um programa (o componente de exibição). Ao criar páginas da Web e aplicações Web com APIs em vez de uma integração totalmente acoplada, você garante que elas possam ser dimensionadas e alteradas com menos reescrita de código.
A seguir, discutiremos outras semelhanças entre as APIs RPC e REST.
Abstração
Embora as comunicações de rede sejam o principal objetivo das APIs, as próprias comunicações de nível inferior são abstraídas dos desenvolvedores de APIs. Isso permite que os desenvolvedores se concentrem na função e não na implementação técnica.
Comunicação
Tanto a REST quanto a RPC usam HTTP como protocolo subjacente. Os formatos de mensagem mais populares em RPC e REST são JSON e XML. O JSON é preferido devido à sua legibilidade e flexibilidade.
Compatibilidade entre linguagens
Os desenvolvedores podem implementar uma API RESTful ou RPC em qualquer linguagem de sua escolha. Desde que o elemento de comunicação de rede da API esteja em conformidade com o padrão de interface RESTful ou RPC, você poderá escrever o resto do código em qualquer linguagem de programação.
Princípios da arquitetura: RPC versus REST
Na Chamada de Procedimento Remoto (RPC), o cliente faz uma chamada de função remota (também conhecida como método ou procedimento) em um servidor. Normalmente, um ou mais valores de dados são passados para o servidor durante a chamada.
Por outro lado, o cliente REST solicita que o servidor execute uma ação em um recurso específico do servidor. As ações são limitadas somente a criar, ler, atualizar e excluir (CRUD) e são transmitidas como verbos HTTP ou métodos HTTP.
A RPC se concentra em funções ou ações, enquanto a REST se concentra em recursos ou objetos.
Princípios da RPC
A seguir, discutiremos alguns princípios que os sistemas RPC normalmente seguem. No entanto, esses princípios não são padronizados como a REST.
Invocação remota
Uma chamada RPC é feita por um cliente para uma função no servidor remoto, como se ela tivesse sido chamada localmente para o cliente.
Parâmetros de passagem
O cliente normalmente envia parâmetros para uma função do servidor, da mesma forma que uma função local.
Stubs
Os stubs de função existem tanto no cliente quanto no servidor. No lado do cliente, ele faz a chamada da função. No servidor, ele invoca a função real.
Princípios da REST
Os princípios da REST são padronizados. Uma API REST deve seguir esses princípios para ser classificada como RESTful.
Cliente-servidor
A arquitetura cliente-servidor da REST desacopla clientes e servidores. Ela trata cada um deles como sistemas independentes.
Sem estado
O servidor não mantém nenhum registro do estado do cliente entre as solicitações do cliente.
Capacidade de armazenamento em cache
O cliente ou os sistemas intermediários podem armazenar em cache as respostas do servidor desde que o cliente especifique que a resposta pode ser armazenada em cache.
Sistema em camadas
Podem existir intermediários entre o cliente e o servidor. Tanto o cliente quanto o servidor não têm conhecimento disso e operam como se estivessem diretamente conectados.
Interface uniforme
O cliente e o servidor se comunicam por meio de um conjunto padronizado de instruções e formatos de mensagens com a API REST. Os recursos são identificados por sua URL, e essa URL é conhecida como endpoint da API REST.
Como eles funcionam: RPC versus REST
Na Chamada de Procedimento Remoto (RPC), o cliente usa HTTP POST para chamar uma função específica pelo nome. Os desenvolvedores do lado do cliente devem saber o nome e os parâmetros da função com antecedência para que a RPC funcione.
Na REST, clientes e servidores usam verbos HTTP como GET, POST, PATCH, PUT, DELETE e OPTIONS para executar as opções. Os desenvolvedores só precisam conhecer as URLs dos recursos do servidor e não precisam se preocupar com nomes de funções individuais.
A tabela a seguir mostra o tipo de código que o cliente usa para realizar ações semelhantes em RPC e REST.
| Ação |
RPC |
REST |
Comentário |
| Adicionar um novo produto a uma lista de produtos |
POST /addProduct HTTP/1.1 HOST: api.example.com Tipo de conteúdo: aplicação/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
POST /produtos HTTP/1.1 HOST: api.example.com Tipo de conteúdo: aplicação/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
A RPC usa POST na função e a REST usaPOST na URL. |
| Recuperando os detalhes de um produto |
POST /getProduct HTTP/1.1 HOST: api.example.com Tipo de conteúdo: aplicação/json {"productID": "123”} |
GET /produtos/123 HTTP/1.1 HOST: api.example.com |
A RPC usa POST na função e passa o parâmetro como objeto JSON. A REST usa GET na URL e passa o parâmetro na URL. |
| Atualizando o preço de um produto |
POST /updateProductPrice HTTP/1.1 HOST: api.example.com Tipo de conteúdo: aplicação/json {"productId": "123", "newPrice": "20.00"} |
PUT /produtos/123 HTTP/1.1 HOST: api.example.com Tipo de conteúdo: aplicação/json {"price": "20.00"} |
A RPC usa POST na função e passa o parâmetro como objeto JSON. A REST usa PUT na URL e passa o parâmetro na URL e como objeto JSON. |
| Excluindo um produto |
POST /deleteProduct HTTP/1.1 HOST: api.example.com Tipo de conteúdo: aplicação/json {"productId": "123""} |
DELETE /produtos/123 HTTP/1.1 HOST: api.example.com |
A RPC usa POST na função e passa o parâmetro como objeto JSON. A REST usa DELETE na URL e passa o parâmetro na URL. |
Principais diferenças: versus REST
Apresentamos mais algumas diferenças abaixo.
Época do desenvolvimento
A RPC foi desenvolvida no final dos anos 1970 e início dos anos 1980, enquanto a REST foi um termo cunhado pela primeira vez pelo cientista da computação Roy Fielding no ano 2000.
Formato operacional
Uma API REST tem um conjunto padronizado de operações de servidor devido aos métodos HTTP, mas as APIs RPC não. Algumas implementações de RPC fornecem uma estrutura para operações padronizadas.
Formato da transmissão de dados
A REST pode transmitir qualquer formato de dados e vários formatos, como JSON e XML, na mesma API.
No entanto, com as APIs RPC, o formato dos dados é selecionado pelo servidor e corrigido durante a implementação. Você pode ter implementações específicas de JSON RPC ou XML RPC e o cliente não tem flexibilidade.
Estado
No contexto das APIs, sem estado refere-se a um princípio de design em que o servidor não armazena nenhuma informação sobre as interações anteriores do cliente. Cada solicitação de API é tratada de forma independente e o servidor não depende de nenhum estado do cliente armazenado para processar a solicitação.
Os sistemas REST devem sempre ser sem estado, mas os sistemas RPC podem ter ou não estado, dependendo do design.
Quando usar: RPC versus REST
A Chamada de Procedimento Remoto (RPC) geralmente é usada para chamar funções remotas em um servidor que exige um resultado de ação. Você pode usá-la quando precisar de cálculos complexos ou quiser acionar um procedimento remoto no servidor, com o processo oculto do cliente.
Estas são algumas ações nas quais a RPC é uma boa opção:
- Tirar uma foto com a câmera de um dispositivo remoto
- Usar um algoritmo de machine learning no servidor para identificar fraudes
- Transferir dinheiro de uma conta para outra em um sistema bancário remoto
- Reiniciar um servidor remotamente
Normalmente, uma API REST é usada para realizar operações de criação, leitura, atualização e exclusão (CRUD) em um objeto de dados em um servidor. Isso torna as APIs REST uma boa opção para casos em que dados e estruturas de dados do servidor precisam ser expostos uniformemente.
Estas são algumas ações nas quais uma API REST é uma boa opção:
- Adicionar um produto a um banco de dados
- Recuperar o conteúdo de uma playlist de músicas
- Atualizar o endereço de uma pessoa
- Excluir uma postagem de blog
Por que a REST substituiu a RPC?
Embora as APIs Web REST sejam a norma atualmente, a Chamada de Procedimento Remoto (RPC) não desapareceu. Normalmente, uma API REST é usada nas aplicações, pois é mais fácil para os desenvolvedores entenderem e implementarem. No entanto, a RPC ainda existe e é usada quando for mais adequada ao caso de uso.
Implementações modernas de RPC, como gRPC, agora são mais usadas. Em alguns casos de uso, a gRPC tem uma performance melhor do que a RPC ou a REST. Ela permite o streaming das comunicações cliente-servidor em vez do padrão de troca de dados de solicitação e resposta.
Resumo das diferenças: RPC versus REST
| RPC |
REST |
|
| O que é isso? |
Um sistema permite que um cliente remoto chame um procedimento em um servidor como se fosse local. |
Um conjunto de regras que define a troca estruturada de dados entre um cliente e um servidor. |
| Usada para |
Executar ações em um servidor remoto. |
Operações de criação, leitura, atualização e exclusão (CRUD) em objetos remotos. |
| O mais adequado |
Quando forem necessários cálculos complexos ou ao acionar um processo remoto no servidor. |
Quando os dados e estruturas de dados do servidor precisarem ser expostos uniformemente. |
| Condição com estado |
Com estado ou sem estado. |
Sem estado. |
| Formato da transmissão de dados |
Em uma estrutura consistente definida pelo servidor e aplicada ao cliente. |
Em uma estrutura determinada de forma independente pelo servidor. Vários formatos diferentes podem ser transmitidos na mesma API. |
Como a AWS pode oferecer suporte aos seus requisitos de API?
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 serviços da AWS que podem ajudar você a cumprir 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 REST 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 permite o gerenciamento contínuo do tráfego gRPC em arquiteturas de software sem alterar nenhuma infraestrutura subjacente para os clientes ou serviços dos clientes.
- 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 as APIs REST e as APIs de Remote Procedure Call (RPC – Chamada de procedimento remoto) na AWS criando uma conta hoje mesmo.
