Arquitetura REST
1 INTRODUÇÃO
REST nasceu da tese de doutorado de Roy Fielding em 2000. O trabalho definiu um estilo arquitetural, não um protocolo específico. A confusão entre estilo e protocolo persiste até hoje em muitos times de engenharia.
A sigla significa Representational State Transfer. O foco sempre esteve em recursos identificados por URIs estáveis. Cada recurso pode ter diferentes representações, como JSON ou XML.
Chamar qualquer API HTTP de REST virou prática comum. Isso dilui o significado técnico do termo.
2 FUNDAMENTAÇÃO TEÓRICA
Fielding propôs seis restrições que definem um sistema RESTful. A maioria das APIs no mercado ignora pelo menos metade delas.
A primeira restrição é a separação entre cliente e servidor. Ela garante evolução independente das duas pontas. A interface vira o único contrato entre eles.
A segunda restrição exige requisições stateless. O servidor não guarda contexto entre chamadas consecutivas. Toda informação precisa viajar junto com a requisição. Sessão em memória quebra esse princípio fundamental.
Cache é a terceira restrição importante. Respostas devem sinalizar se podem ser armazenadas ou não.
A quarta restrição é a interface uniforme. Aqui mora a parte mais mal interpretada do estilo. Fielding exige identificação clara de recursos por URI. Exige manipulação desses recursos através de representações. Exige mensagens autodescritivas. Exige HATEOAS.
Quase ninguém implementa HATEOAS direito. O cliente deveria navegar pela API seguindo links na própria resposta. Na prática, documentação Swagger substituiu essa ideia original.
A quinta restrição trata de sistemas em camadas. Um proxy ou balanceador pode existir sem o cliente saber. Isso permite escalar infraestrutura sem quebrar a interface pública.
A sexta restrição é opcional. Chama-se code on demand. O servidor pode mandar código executável para o cliente. Poucos sistemas modernos usam essa brecha.
HTTP virou o protocolo padrão para APIs REST. A escolha aconteceu por conveniência histórica, não por exigência teórica. Fielding ajudou a escrever a especificação do HTTP 1.1. A sinergia entre os dois trabalhos foi natural.
Os verbos HTTP mapeiam operações sobre recursos. GET lê um recurso sem efeitos colaterais. POST cria algo novo dentro de uma coleção. PUT substitui um recurso inteiro por completo. PATCH aplica modificações parciais em um recurso. DELETE remove o recurso identificado pela URI.
Idempotência importa mais do que parece. GET, PUT e DELETE precisam ser idempotentes por contrato. POST não tem essa obrigação.
Códigos de status HTTP comunicam o resultado da operação. A faixa 2xx indica sucesso. A faixa 4xx aponta erro do cliente. A faixa 5xx denuncia falha no servidor. Devolver 200 para qualquer coisa é anti-padrão comum.
Segundo Fielding (2000), as restrições induzem propriedades como escalabilidade, simplicidade e desempenho.
Richardson e Ruby (2007) descrevem um modelo de maturidade para APIs. O nível zero usa HTTP apenas como transporte bruto. O nível três implementa HATEOAS completo. A maioria das APIs comerciais fica entre nível um e dois. Uma API que retorna JSON sobre HTTP não é automaticamente RESTful.
Massé (2011) sugere regras práticas para desenhar URIs consistentes. Substantivos no plural funcionam melhor do que verbos. A hierarquia nos paths reflete relacionamento entre recursos.
3 CONCLUSÃO
REST tem limitações reais que poucos times discutem abertamente. Payloads tendem a crescer em chamadas encadeadas. Versionamento de API gera decisões arquiteturais difíceis. Operações que não mapeiam em CRUD viram ginástica de URI.
GraphQL e gRPC apareceram para resolver dores específicas do REST. Isso não torna REST obsoleto. Cada estilo resolve problemas diferentes.
Para sistemas com muitos consumidores públicos, REST continua sendo a escolha mais segura. A curva de aprendizado é baixa. Ferramentas de cache e proxy funcionam de graça.
Para comunicação interna entre microsserviços, outras opções costumam vencer. Latência e tipagem forte pesam mais nesse cenário.
O erro mais grave é adotar REST sem entender as restrições. O time acaba construindo RPC disfarçado. O resultado tem o pior de cada mundo.
REST envelheceu bem porque suas restrições atacam problemas reais de sistemas distribuídos. Ignorar a teoria por trás desperdiça a principal vantagem do estilo.
4 REFERÊNCIAS BIBLIOGRÁFICAS
FIELDING, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. 2000. Tese (Doutorado em Information and Computer Science) – University of California, Irvine, 2000. Disponível em: https://ics.uci.edu/~fielding/pubs/dissertation/top.htm. Acesso em: 20 abr. 2026.
MASSÉ, Mark. REST API Design Rulebook. Sebas
Top comments (0)