Estado é qualquer informação que precisa ser lembrada entre uma requisição e a próxima. A diferença está em quem guarda esse estado.

POST /login
{ "usuario": "ana", "senha": "123" }

// Servidor cria na memória:
// session["abc123"] = { userId: 7 }
Set-Cookie: sessionId=abc123

POST /carrinho/adicionar
Cookie: sessionId=abc123
{ "produtoId": 42 }
// Busca sessão na memória ✓

GET /carrinho
Cookie: sessionId=abc123
// ❌ Servidor 2 não tem a sessão
// → carrinho vazio ou 401

POST /login
{ "usuario": "ana", "senha": "123" }

// Servidor NÃO guarda nada.
// Gera token assinado:
{ "token": "eyJhbGci...ana.7" }

POST /carrinho/itens
Authorization: Bearer eyJ...
{ "produtoId": 42 }
// Valida token, extrai userId=7

GET /carrinho
Authorization: Bearer eyJ...
// ✓ Qualquer servidor valida
// → 200 OK + dados do banco

# Token = 3 partes em Base64, separadas por ponto

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjcsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxOH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header:     { "alg": "HS256", "typ": "JWT" }
Payload:    { "userId": 7, "role": "admin", "exp": 1718000000 }
Assinatura: HMAC-SHA256(header + "." + payload, SECRET)

const jwt = require('jsonwebtoken');

function autenticar(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ erro: 'Token ausente' });
  try {
    // Valida assinatura e extrai payload — zero banco
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    req.userId = payload.userId;
    req.role   = payload.role;
    next();
  } catch {
    res.status(401).json({ erro: 'Token inválido ou expirado' });
  }
}

No modelo RESTful, qualquer desenvolvedor que chegue na API já sabe o que DELETE /pedidos/99 faz — é autoexplicativo. No modelo RPC, você precisa ler a documentação de cada endpoint individualmente. REST usa o protocolo HTTP como vocabulário, tornando a API previsível e consistente.

Queries muito complexas podem sobrecarregar o banco — um cliente pode pedir produtos → pedidos → usuários → pedidos de cada usuário → produtos de cada pedido, criando um grafo enorme. Exige proteção com depth limit e query cost analysis.

RPC é um modelo de comunicação onde um programa chama uma função que roda em outro computador — mas o código parece uma chamada de função local. O programador não precisa pensar em sockets, serialização ou protocolo de rede. Ele simplesmente chama uma função.

# Função está no mesmo processo
resultado = calcularFrete(
  origem="SP",
  destino="RJ",
  peso=2.5
)
print(resultado)  # R$ 18.90

# Função roda em outro servidor!
# O código parece idêntico:
resultado = calcularFrete(
  origem="SP",
  destino="RJ",
  peso=2.5
)
print(resultado)  # R$ 18.90

Por baixo, a chamada RPC viaja pela rede, é executada no servidor remoto e o resultado volta. Mas o desenvolvedor vê apenas uma função sendo chamada.

Pense no RPC como ligar para um serviço de informações. Você fala um pedido ("qual o horário do voo 1234?"), alguém do outro lado consulta o sistema e te passa a resposta. Você não sabe como eles buscaram — só sabe que pediu e recebeu.

Cada geração resolveu problemas da anterior. O gRPC é a versão moderna — com HTTP/2, Protocol Buffers e suporte nativo a streaming.

Nas décadas de 1990 e 2000, o padrão era SOAP (Simple Object Access Protocol) — um formato RPC baseado em XML. Funcionava, mas era verboso ao extremo, difícil de debugar e lento.

<!-- 📦 SOAP Request — buscar produto -->
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <loja:GetProduto>
      <loja:id>42</loja:id>
    </loja:GetProduto>
  </soapenv:Body>
</soapenv:Envelope>

<!-- vs gRPC — a mesma chamada em Protobuf binário -->
# 0x0A 02 34 32  (4 bytes — id="42")

O gRPC surgiu porque o Google precisava de uma forma de fazer microsserviços se comunicarem com performance máxima, contrato rígido e suporte a múltiplas linguagens — e nenhuma das soluções existentes entregava os três ao mesmo tempo.

syntax = "proto3";

message Produto {
  string id        = 1;
  string nome      = 2;
  float  preco     = 3;
  int32  estoque   = 4;
}

message ProdutoRequest {
  string id = 1;
}

service ProdutoService {
  rpc GetProduto(ProdutoRequest) returns (Produto);
  rpc ListarProdutos(Empty) returns (stream Produto);
}

Os números (= 1, = 2...) são IDs de campo usados na serialização binária. Nunca mude um número em produção — quebra compatibilidade com clientes antigos.

Muitos sistemas usam Redis para armazenar sessões — ainda é tecnicamente stateful, mas melhor: o estado sai da memória local do servidor e vai para um armazenamento centralizado. Resolve o scale, mas ainda é mais complexo que JWT puro. A escolha depende de um trade-off: JWT é mais simples, mas não pode ser revogado imediatamente; sessão em Redis pode ser invalidada na hora, mas exige a infraestrutura extra.

# Token = 3 partes separadas por ponto, cada uma em Base64

eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjcsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxOH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header:     { "alg": "HS256", "typ": "JWT" }
Payload:    { "userId": 7, "role": "admin", "exp": 1718000000 }
Assinatura: HMAC-SHA256(header + "." + payload, SECRET)

O servidor valida a assinatura com sua chave secreta. Se alguém alterar o payload, a assinatura não bate — token rejeitado automaticamente.

const jwt = require('jsonwebtoken');

function autenticar(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];

  if (!token) return res.status(401).json({ erro: 'Token ausente' });

  try {
    // Valida assinatura e extrai payload — zero banco
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    req.userId = payload.userId;
    req.role   = payload.role;
    next();
  } catch {
    res.status(401).json({ erro: 'Token inválido ou expirado' });
  }
}

// Uso em qualquer rota
app.get('/perfil', autenticar, (req, res) => {
  res.json({ mensagem: `Olá, usuário ${req.userId}` });
});

Um sistema moderno tipicamente combina as três em camadas: