This content originally appeared on DEV Community and was authored by Alberto Luiz Souza
Introdução
REST é um dos temas mais debatidos entre desenvolvedores nas mais variadas empresas. Projetos e mais projetos são desenvolvidos baseados nesse estilo arquitetural, mas será que realmente entendemos o que Roy Fielding estava pensando quando o definiu? Neste post, vamos revisar o artigo original e entender o real papel do REST dentro da web e como ele se conecta com as aplicações que desenvolvemos.
O Escopo da Arquitetura REST
O primeiro ponto importante é entender que REST foi pensado para arquiteturas em nível de aplicação, não apenas de rede. Isso significa que REST se preocupa com o contexto de cada requisição: Por que ela está sendo feita? Devemos fazer cache? Qual o melhor formato de resposta? É diferente de arquiteturas focadas apenas em rede, cujo único objetivo é levar bits de um ponto a outro.
Roy Fielding utilizou insights de diversas outras arquiteturas de rede para compor o REST. Ele nunca poderia ter criado o REST se não fosse um especialista em arquiteturas de sistemas distribuídos e protocolos de rede, conhecendo profundamente a web e seus desafios naquela época.
Escalabilidade Anárquica: O Desafio da Web
Um conceito fundamental introduzido é o de “escalabilidade anárquica”. Fielding percebeu que uma arquitetura pensada para a web não poderia prever qual seria a carga de requisições em determinado momento. A web crescia exponencialmente e qualquer arquitetura proposta precisava suportar essa imprevisibilidade.
A web foi vítima do seu próprio sucesso. As primeiras versões do HTTP não imaginavam que uma página precisaria de múltiplas requisições para ser exibida – pensava-se em documentos de texto simples. Mas rapidamente as páginas passaram a incluir imagens, scripts e outros recursos, exigindo uma evolução dos protocolos.
A Definição Formal de REST
REST (Representational State Transfer) foi desenvolvido pensando na web moderna e no futuro. A definição formal é clara: “REST é um estilo híbrido derivado de várias arquiteturas de rede combinado com restrições adicionais que definem um conector de interface uniforme”.
É importante notar que o protocolo HTTP foi inspirado pelo estilo arquitetural REST, não o contrário. A versão 1.1 do HTTP foi criada usando REST como base arquitetural.
As Restrições Fundamentais do REST
1. Cliente-Servidor
A primeira restrição é suportar o modelo cliente-servidor. O cliente é responsável pela interface do usuário, enquanto o servidor mantém os dados. Isso permite que ambos evoluam independentemente.
2. Stateless (Sem Estado)
Toda requisição deve levar todas as informações necessárias para ser processada. Isso é crucial para escalabilidade, pois elimina estado compartilhado entre servidores e facilita o monitoramento (visibility) das requisições.
3. Cache
O cache é fundamental para performance. Servidores devem informar nas respostas se e por quanto tempo elas podem ser cacheadas. Clientes podem então decidir se usam essas informações para evitar requisições desnecessárias.
4. Interface Uniforme
Esta é a característica que diferencia REST de outros estilos arquiteturais. REST define uma forma uniforme de comunicação que suporta diversos tipos de dados (JSON, XML, HTML, imagens, etc.) com seus respectivos metadados.
5. Sistema em Camadas (Layered System)
A arquitetura deve suportar múltiplas camadas intermediárias entre cliente e servidor. Cada camada só conhece a camada adjacente, criando proteção contra mudanças e possibilitando cache compartilhado.
6. Código sob Demanda (Code on Demand)
O cliente deve ser capaz de executar código que não foi escrito por ele. O navegador é o exemplo perfeito: executa JavaScript recebido dos servidores, com infraestrutura para detectar código malicioso e proteger o usuário.
O Navegador: A Única Aplicação Verdadeiramente REST
Ao analisar as aplicações modernas, percebemos que apenas o navegador implementa completamente os conceitos REST:
- Executa código sob demanda
- Evolui independentemente dos servidores
- Adapta-se a mudanças de contrato automaticamente
- Implementa cache baseado em headers HTTP
- Detecta código malicioso e protege o usuário
- Gerencia redirecionamentos automaticamente
Especificamente sobre Cache
A estratégia de cache descrita no artigo é um recurso que poderia ser bem mais utilizado. A minha observação me diz que a maioria das aplicações usam os recursos de cache dentro apenas do próprio serviço de backend e através de CDN’s e afins para facilitarem o consumo do navegador.
Por exemplo, pensando em serviços distribuídos do lado do backend, quase nunca vemos um serviço B definindo um header de cache e o serviço A respeitar o cache a partir do consumo dessa informação, que é justamente o que o navegador faz.
Esta é uma ideia que está lá escrita faz tempo e fornece o caminho para implementarmos uma ideia básica: A melhor requisição é aquela que nunca é feita.
A Realidade das Aplicações Modernas
O ano é 2025 e várias das aplicações ainda ficam ultra focadas na interface uniforme, se preocupando com verbos e content-types.
Para mim as principais inspirações são: Seja stateless o máximo que conseguir, faça com que seus endpoints utilizem headers que possam guiar o comportamento do cliente e, por fim, faça clientes inspirados no navegador.
Conclusão
REST é um estilo arquitetural que considero excepcional e foi pensado para resolver problemas de escala planetária. Entender seus princípios é importante e pode ser bem inspirador.
Dev+ Eficiente
Se você gostou deste conteúdo, conheça a Jornada Dev + Eficiente, nosso treinamento focado em fazer com que você se torne uma pessoa cada vez mais capaz de entregar software que gera valor na ponta final, com máximo de qualidade e eficiência.
Acesse https://deveficiente.com/oferta-20-por-cento para conhecer tudo que oferecemos.
This content originally appeared on DEV Community and was authored by Alberto Luiz Souza