Arquitetura REST

Source: Dev.to

# 1 INTRODUÇÃO

No cenário atual do desenvolvimento de software, a integração entre sistemas heterogêneos deixou de ser uma exceção e virou regra. Com a popularização das aplicações em rede, os **Web Services** se tornaram a espinha dorsal dessa comunicação. Dentre as várias abordagens arquiteturais que estudamos no curso, o **Representational State Transfer (REST)** acabou se consolidando como o verdadeiro padrão de mercado para a construção de APIs.

Um erro comum — e que muitas vezes confunde quem está começando a programar — é achar que o REST é um protocolo fechado ou um framework que você instala no projeto. Na verdade, ele é um **estilo arquitetural**. Esse conceito foi introduzido por **Roy Thomas Fielding** no ano 2000, durante sua tese de doutorado. A grande sacada de Fielding foi abstrair como a própria web funciona, estabelecendo um conjunto de restrições lógicas para guiar o design de aplicações, visando o máximo de escalabilidade e confiabilidade nas interações (Fielding, 2000).

O objetivo deste artigo é apresentar os fundamentos teóricos da arquitetura REST. Para isso, vamos explorar suas restrições principais, discutir a ideia de maturidade arquitetural (dando foco ao **HATEOAS**) e fazer um comparativo rápido com outras soluções do mercado, como o **SOAP** e o **GraphQL**, além de citar como isso se aplica no mundo real.

---

# 2 FUNDAMENTAÇÃO TEÓRICA

Para que um serviço web seja de fato considerado *RESTful*, ele não pode apenas usar o HTTP de qualquer jeito; ele precisa seguir rigorosamente um conjunto de restrições de design. Como aponta **Lecheta (2015)**, são essas regras que garantem que o sistema distribuído fique simples de entender e fácil de manter.

## 2.1 Restrições Principais

1. **Separação de responsabilidades (Client‑Server)**  
   - Permite que a interface (front‑end) evolua totalmente independente do armazenamento de dados (back‑end).

2. **Stateless (sem estado)**  
   - O servidor não guarda informações da sessão do usuário entre requisições. Cada requisição deve conter todas as informações necessárias para ser compreendida e processada (Fielding, 2000).  
   - Facilita o balanceamento de carga em provedores de nuvem, pois qualquer servidor disponível pode atender qualquer requisição.

3. **Interface uniforme**  
   - Recursos são identificados de forma única usando **URIs** (Uniform Resource Identifiers).  
   - São manipulados por meio de suas representações (JSON é o formato mais usado).  
   - Os verbos HTTP têm significado semântico: `GET` (buscar), `POST` (criar), `PUT/PATCH` (atualizar) e `DELETE` (remover) (Lecheta, 2015).

## 2.2 Maturidade Arquitetural – Modelo de Richardson

Nem toda API que se diz “REST” realmente segue o estilo. O **Modelo de Maturidade de Richardson** classifica as APIs em quatro níveis (0 – 3). O nível mais avançado (Nível 3) é atingido quando aplicamos o conceito de **HATEOAS** (Hypermedia as the Engine of Application State). Nesse nível, a resposta do servidor já traz *links* de hipermídia que guiam o cliente sobre as próximas ações permitidas, reduzindo a dependência do front‑end em relação à estrutura exata do back‑end (Richardson & Amundsen, 2013).

## 2.3 Comparativo com Outras Abordagens

| Característica                     | **REST**                              | **SOAP**                              | **GraphQL**                           |
|------------------------------------|--------------------------------------|--------------------------------------|--------------------------------------|
| **Formato de mensagem**           | JSON (ou XML)                         | XML (envelopes rígidos)               | JSON (consultas flexíveis)           |
| **Contrato**                       | Implícito (URI + verbos)              | Estrito (WSDL)                        | Implícito (esquema GraphQL)          |
| **Cache nativo**                   | Sim (HTTP)                            | Não                                   | Não (precisa de camada extra)        |
| **Over/Under‑fetching**            | Possível (dependendo do endpoint)    | Não aplicável                         | Evita ambos (consulta sob demanda)   |
| **Complexidade de implementação** | Baixa                                 | Alta (requere WS‑Security, etc.)     | Média (necessita schema + resolvers) |
| **Casos de uso típicos**           | APIs públicas, micro‑serviços        | Sistemas legados, transações corporativas | Aplicações mobile, UI‑intensivas     |

*Como podemos ver, o SOAP (Serrano; Hernantes; Gallardo, 2014) ainda tem seu espaço, mas costuma ficar restrito a sistemas legados ou corporativos que exigem contratos absurdamente rígidos. Já o GraphQL vem ganhando muita tração porque resolve perfeitamente os problemas de **overfetching** (trazer dados que não vão ser usados) e **underfetching** (precisar de várias requisições para montar uma view única), o que é excelente para conexões mobile instáveis (Seabra; Pinto, 2019). Mesmo assim, o REST continua vantajoso por causa da sua curva de aprendizado menor, do suporte nativo ao cache da web e da simplicidade no roteamento.*

## 2.4 Aplicação Real – Informática em Saúde

A área de **Informática em Saúde** é um ótimo exemplo de uso de REST. Barreto (2020) propõe arquiteturas de referência em e‑saúde (como o **H‑KaaS**) que mostram como o compartilhamento e a gestão de conhecimento complexo dependem de interfaces padronizadas. Além disso, o padrão global **FHIR** (Fast Healthcare Interoperability Resources), usado para conectar prontuários eletrônicos pelo mundo todo, aplica exatamente os princípios RESTful para garantir que dados críticos trafeguem com segurança e integridade.

---

# 3 CONCLUSÃO

Ao longo das disciplinas do curso, fica claro que a arquitetura REST extrapolou a tese original de Fielding para se tornar o “feijão com arroz” do design de aplicações modernas. O uso consciente de suas restrições — com destaque para a comunicação **stateless**, o aproveitamento de **cache** nativo e a **interface uniforme** — nos permite projetar softwares altamente escaláveis, algo essencial quando pensamos no volume de acessos dos sistemas de hoje em dia.

É verdade que o mercado vive de novidades e que tecnologias voltadas para a otimização da entrega de dados, como o GraphQL, têm um papel importantíssimo nas arquiteturas de front‑end mais modernas. Contudo, quando se trata de usar o protocolo HTTP de maneira idiomática (da forma como ele foi desenhado para funcionar), o REST segue imbatível.

Para nós, futuros engenheiros de software, o verdadeiro desafio não está em substituir o REST, mas sim em parar de utilizá‑lo pela metade. O foco deve ser buscar os **níveis** de maturidade mais avançados, adotando HATEOAS e boas práticas de versionamento, para que nossas APIs sejam verdadeiramente resilientes e evolutivas.

Texto

“Os níveis mais altos de maturidade arquitetural exigem a adoção de boas práticas. Implementar o HATEOAS, por exemplo, ainda é a chave principal para garantir um baixo acoplamento, criando sistemas que sejam autoexplicativos, robustos e que consigam evoluir sem gerar dor de cabeça no longo prazo.”

Referências

1. BARRETO, R. G. H‑KaaS: Uma arquitetura de referência baseada em conhecimento como serviço para e‑saúde. 2020. 121 f. Dissertação (Mestrado em Informática) – Universidade Federal da Paraíba, João Pessoa, 2020.
2. FIELDING, R. T. Architectural styles and the design of network‑based software architectures. 2000. 162 f. Tese (Doutorado em Ciência da Computação) – University of California, Irvine, 2000.
3. LECHETA, R. R. Web services RESTful: aprenda a criar web services RESTful em Java na nuvem do Google. São Paulo: Novatec, 2015.
4. RICHARDSON, L.; AMUNDSEN, M. RESTful Web APIs. Sebastopol: O’Reilly Media, 2013.
5. SEABRA, M.; PINTO, G. “REST or GraphQL? A performance comparative study.” In: SBCARS ’19: Proceedings of the XIII Brazilian Symposium on Software Components, Architectures, and Reuse. Salvador: ACM, 2019, p. 123‑132.
6. SERRANO, N.; HERNANTES, J.; GALLARDO, G. “Service‑oriented architecture and legacy systems.” IEEE Software, Los Alamitos, v. 31, n. 5, p. 15‑19, 2014.