Disclaimer

Este texto foi inicialmente concebido pela IA Generativa em função da transcrição do episódio do nosso canal, Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play.

Introdução

Neste post, vamos revisitar um artigo escrito por Roy Fielding sobre REST (Representational State Transfer) para entender melhor o papel desse estilo arquitetural na web e sua conexão com as aplicações desenvolvidas atualmente.

REST é um tema que gera/gerou intensos debates entre as pessoas desenvolvedoras, sendo amplamente utilizado em projetos. Portanto, é fundamental relembrar suas premissas e refletir sobre como ele é aplicado hoje em dia.

Restrição do Escopo e Arquitetura de Aplicação

O artigo de Fielding define o escopo da discussão, focando em arquiteturas a nível de aplicação. Diferentemente das arquiteturas distribuídas de rede, que se concentram apenas na transmissão de dados, as arquiteturas de aplicação se preocupam com o contexto e o motivo de cada requisição entre cliente e servidor.

Fielding menciona que usou insights de outras arquiteturas de rede para compor o REST, enfatizando que novas ideias surgem através da conexão de informações prévias.

Ele destaca que arquiteturas pensadas para a web devem supor a transferência de grandes quantidades de dados e abraçar o seu processo evolutivo. Importante notar que ele aqui estava influenciado pela transformação que as páginas da época estavam passando.

A Web e a Escalabilidade Anárquica

Um conceito interessante mencionado no artigo é a "escalabilidade anárquica", que se refere à imprevisibilidade da carga de requisições na web devido ao seu crescimento exponencial e uso global.

É mencionado que a web foi vítima do seu próprio sucesso, pois as primeiras versões do protocolo HTTP não foram projetadas para lidar com páginas que exigiam mais de uma requisição para serem exibidas.

Inicialmente, imaginava-se que seriam apenas documentos de texto simples, mas a evolução da web mostrou um cenário muito mais rico, com páginas contendo diversos elementos e requisições adicionais.

Fielding observou esse processo de evolução e propôs o REST como um novo estilo arquitetural para suportar as evoluções futuras da web. O protocolo HTTP também passou por atualizações, como o HTTP 1.1 e o HTTP 2, visando atender às demandas do uso moderno da web.

Definição Formal do REST

No capítulo 5 do artigo, Fielding descreve formalmente o REST como "um estilo híbrido derivado de várias arquiteturas de rede combinado com restrições adicionais que definem um conector de interface uniforme".

O autor explica que existem dois modos de definir uma arquitetura: partindo do zero, sem restrições, ou considerando um conjunto de restrições e um contexto bem definido, como era o caso da web naquele momento. O REST foi proposto a partir das restrições existentes, visando abraçar o funcionamento da web e possibilitar sua evolução.

Restrições do REST

Fielding define várias restrições que compõem o estilo arquitetural REST:

  1. Suportar o estilo cliente-servidor, fundamental para a web. O cliente é responsável pela interface do usuário e pela renderização das informações, enquanto o servidor possui os dados e as informações a serem fornecidas.
  2. Stateless - cada requisição deve conter todas as informações necessárias para ser processada pelo servidor, o que é essencial para a escalabilidade.
  3. Cache - para melhorar a performance, o servidor deve indicar se a resposta pode ser cacheada pelo cliente, definindo as restrições de tempo de cache.
  4. Interface uniforme - um modo uniforme de comunicação entre cliente e servidor, suportando a transferência de diversos tipos de dados. O elemento que distingue a proposta do REST de outras propostas arquiteturais.
  5. Sistema em camadas - Aqui é trazida a ideia padrão de um sistema em camadas. Complexidades podem ser abstraídas e, do ponto de vista de quem usa, tudo continua igual.
  6. Code-on-demand - o cliente deve ser capaz de executar código fornecido pelo servidor. Para tangibilizar, pense que o navegador executa código Javascript direto na sua máquina.

Reflexões e Questionamentos

Podemos ter algumas reflexões sobre como os conceitos do REST são aplicados atualmente. Vamos usar como benchmark de comparação o navegador, que provavelmente é a melhor implementação de um cliente REST que existe no mundo.

  • Muitas SPAs (Single Page Applications) quebram a premissa de que o cliente pode evoluir de maneira distinta do servidor, pois alterações nos contratos de endpoint podem quebrar a aplicação. O seu navegador não desaprende a renderizar páginas porque você trocou links para css, javascript etc.
  • Podemos fazer melhor uso do cache, conforme proposto pelo REST. Por exemplo, definindo no cabeçalho da resposta que uma informação pode ser cacheada por um determinado período e verificando isso na aplicação cliente. É a mesma coisa que acontece quando um servidor de recurso estático diz que uma imagem pode ser cacheada.
  • A arquitetura REST foi pensada para grandes transferências de dados, o que é mencionado explicitamente no artigo. O HTTP é um protocolo inspirado neste estilo e logicamente sua implementação segue os princípios estabelecidos. Regularmente existe uma discussão sobre a velocidade de comunicação quando usamos HTTP, comparado com outros protocolos... Ele exige mais dados na transmissão by design, por conta do seu propósito.

Conclusão

O artigo de Fielding nos mostra que o REST é um estilo arquitetural pensado para uma web em escala global e de formas inimagináveis. Isso difere da maioria das aplicações, que são feitas para cenários e públicos específicos. Isso não quer dizer que não devemos usar, longe disso, apenas que precisamos estar conscientes que regularmente estamos utilizando uma bomba para matar uma formiga.

Conhecer as origens e premissas do REST nos ajuda a tomar decisões mais embasadas e a criar sistemas ainda mais escaláveis.

E você, já leu o artigo completo?

Sobre a Jornada Dev + Eficiente

A Jornada Dev + Eficiente é um treinamento focado em fazer você crescer na carreira como uma pessoa cada vez mais especializada em Design e Arquitetura de Software.

A Jornada pavimenta este caminho fazendo com que você seja cada vez mais capaz de colocar código de qualidade em produção com cada vez mais velocidade.

Para conhecer mais, acesse https://deveficiente.com/kr/lp

Author Of article : Alberto Luiz Souza Read full article