Arquitetura REST

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.

A primeira grande restrição é a separação de responsabilidades entre cliente e servidor (Client-Server). Essa separação permite que a interface (o front-end) evolua totalmente independente do armazenamento de dados (o back-end). Além disso, a comunicação precisa ser obrigatoriamente stateless (sem estado). Isso significa que o servidor não guarda informações da sessão do usuário entre uma requisição e outra. Cada requisição que o cliente faz precisa ter em si todas as informações necessárias para ser compreendida e processada (Fielding, 2000). Na prática, desenhar o sistema assim é excelente porque facilita muito o balanceamento de carga (load balancing) em provedores de nuvem: como não há estado salvo, qualquer servidor que estiver disponível pode atender qualquer requisição.

Outro pilar que define o REST é a interface uniforme. Para diminuir o acoplamento da arquitetura, exige-se que os recursos sejam identificados de forma única usando URIs (Uniform Resource Identifiers) e sejam manipulados por meio de suas representações (o JSON acabou virando o queridinho do mercado para isso). Para dizer ao servidor qual é a intenção da nossa requisição, usamos os verbos do próprio protocolo HTTP com valor semântico: GET para buscar, POST para criar, PUT/PATCH para atualizar e DELETE para remover (Lecheta, 2015).

Mas será que toda API comercial que se diz "REST" é realmente REST? Para responder isso, utilizamos o Modelo de Maturidade de Richardson, que classifica as APIs em níveis (de 0 a 3). O ápice estrutural (Nível 3) é atingido quando aplicamos o conceito de HATEOAS (Hypermedia as the Engine of Application State). Segundo Richardson e Amundsen (2013), nesse nível, a resposta do servidor já traz "links" de hipermídia que guiam o cliente sobre quais são as próximas ações permitidas. Isso reduz drasticamente a dependência do front-end em relação à estrutura exata do back-end, permitindo que a API evolua sem quebrar as aplicações de quem a consome.

Para dar um contexto melhor do ecossistema de desenvolvimento, a Tabela 1 compara o REST com outras duas abordagens de integração amplamente discutidas.

Tabela 1 - Comparativo entre Abordagens de Integração de Serviços Web

Fonte: Elaborado pelo autor com base em Lecheta (2015) e Seabra e Pinto (2019).

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 na tela) e underfetching (precisar fazer 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.

Olhando para a aplicação real disso, a área de Informática em Saúde é um ótimo exemplo. 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 tão 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 mais altos de maturidade arquitetural. 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

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.

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.

LECHETA, R. R. Web services RESTful: aprenda a criar web services RESTful em Java na nuvem do Google. São Paulo: Novatec, 2015.

RICHARDSON, L.; AMUNDSEN, M. RESTful Web APIs. Sebastopol: O'Reilly Media, 2013.

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.

SERRANO, N.; HERNANTES, J.; GALLARDO, G. Service-oriented architecture and legacy systems. IEEE Software, Los Alamitos, v. 31, n. 5, p. 15-19, 2014.