Visão geral do REST. Parte 1: O que é REST?

Oi! Hoje vamos aprender sobre um tema muito interessante e, principalmente, muito procurado no mercado de trabalho: REST. Dividiremos nossa visão geral do REST em três partes:

1. Na primeira parte, abordaremos a história do REST e descreveremos os princípios nos quais o REST se baseia.

2. Na segunda, veremos como ocorre a comunicação entre um cliente e um servidor via protocolo HTTP.

3. Na terceira, escreveremos uma pequena aplicação RESTful que testaremos usando um programa chamado "Postman".

O artigo é destinado a leitores familiarizados com os seguintes termos:

• HTTP
• URL e URI
• JSON e (em menor grau) XML
• Injeção de dependência

Parte 1. O que é REST?

REST, como muito no mundo da TI, é um acrônimo. É derivado de "REpresentational State Transfer" . Este é um estilo de arquitetura para interação entre componentes de um sistema distribuído em uma rede de computadores. Simplificando, REST determina o estilo de interação (troca de dados) entre diferentes componentes do sistema, cada um dos quais pode estar fisicamente localizado em lugares diferentes. Esse estilo de arquitetura é um conjunto consistente de restrições aderidas ao projetar um sistema distribuído. Essas restrições às vezes são chamadas de princípios orientadores do REST. Não são muitos, apenas 6. Falaremos deles um pouco mais tarde.

História do REST

O termo REST foi introduzido por Roy Fielding, um dos criadores do protocolo HTTP, em seu Ph.D. tese intitulada "Architectural Styles and the Design of Network-based Software Architectures" em 2000. Embora o termo REST ainda possa ser chamado de jovem, o conceito que ele representa está no cerne da World Wide Web. Não vamos mergulhar fundo na história do termo. Se você quiser mergulhar nas fontes primárias, dê uma olhada na dissertação de Fielding .

Restrições e princípios REST

Conforme declarado acima, REST define como os componentes de um sistema distribuído devem interagir uns com os outros. Em geral, isso acontece por meio de um processo de solicitação-resposta. O componente que envia a requisição é chamado de cliente , e o componente que processa a requisição e envia uma resposta ao cliente é chamado de servidor. Solicitações e respostas são geralmente enviadas por meio do protocolo HTTP. HTTP significa Protocolo de Transferência de Hipertexto. Normalmente, um servidor é algum aplicativo da web. O cliente pode ser quase qualquer coisa. Por exemplo, um aplicativo móvel que solicita dados de um servidor. Ou um navegador que envia solicitações de uma página da web para um servidor para baixar dados. O aplicativo A pode solicitar dados do aplicativo B. Nesse caso, A é um cliente em relação a B e B é um servidor em relação a A. Ao mesmo tempo, A pode processar solicitações de B, C, D etc. Nesse caso, o aplicativo A é um servidor e um cliente. Tudo depende do contexto. Uma coisa é certa: o componente que envia a requisição é o cliente. O componente que recebe, processa e responde a uma requisição é o servidor. No entanto, nem todo sistema cujos componentes se comunicam por meio de um processo de solicitação-resposta é um sistema RESTful. Para que um sistema seja considerado RESTful, ele deve cumprir as seis restrições REST:

1. Arquitetura cliente-servidor

Essa restrição é sobre a separação de preocupações. É necessário separar os requisitos da interface do cliente dos requisitos do servidor que armazena os dados. Essa restrição torna o código do cliente mais portátil para outras plataformas e a simplificação do lado do servidor melhora a escalabilidade do sistema. Fazer uma distinção entre o "cliente" e o "servidor" permite que eles sejam desenvolvidos independentemente um do outro.

2. Apátrida

Uma arquitetura RESTful requer que as seguintes condições sejam atendidas. No período entre requisições, o servidor não deve armazenar informações sobre o estado do cliente e vice-versa. Todas as solicitações do cliente devem ser compostas de forma a fornecer ao servidor todas as informações necessárias para concluir a solicitação. Assim, tanto o servidor quanto o cliente podem "entender" qualquer mensagem recebida, sem depender de mensagens anteriores.

3. Armazenável

Os clientes podem armazenar em cache as respostas do servidor. Estes, por sua vez, devem ser explicitamente ou implicitamente designados como cacheados ou não cacheados, para que os clientes não recebam dados desatualizados ou incorretos em resposta a requisições subsequentes. O cache correto ajuda a eliminar total ou parcialmente algumas interações cliente-servidor, aumentando ainda mais o desempenho e a escalabilidade do sistema.

4. Interface uniforme

Os requisitos fundamentais de uma arquitetura RESTful incluem uma interface unificada e uniforme. O cliente deve sempre entender o formato e os endereços que deve usar ao enviar uma solicitação, e o servidor, por sua vez, também deve entender o formato que deve usar ao responder às solicitações do cliente. Essa interação cliente-servidor consistente que descreve o que, onde, de que forma e como enviar dados é uma interface unificada.

5. Camadas

Por camadas, queremos dizer a estrutura hierárquica da rede. Às vezes, um cliente pode se comunicar diretamente com o servidor e, às vezes, apenas se comunica com um nó intermediário. O uso de servidores intermediários pode aumentar a escalabilidade graças ao balanceamento de carga e cache distribuído. Vamos fornecer um exemplo. Imagine um aplicativo móvel popular em todo o mundo. Uma parte integrante do aplicativo envolve o carregamento de imagens. Seus usuários chegam a milhões, portanto, um único servidor não pode lidar com uma carga tão pesada. Separar o sistema em camadas resolverá esse problema. Se o cliente solicita uma imagem de um nó intermediário, então o nó intermediário solicita a imagem do servidor que está menos carregado no momento e retorna a imagem para o cliente. Se o cache for aplicado corretamente em cada nível da hierarquia,

6. Código sob demanda (opcional)

Essa restrição implica que o cliente pode expandir sua funcionalidade baixando o código do servidor na forma de applets ou scripts.

Vantagens de uma arquitetura RESTful

Aplicações que cumprem todas as restrições mencionadas apresentam as seguintes vantagens: confiabilidade (não há necessidade de salvar o estado do cliente, que pode ser perdido)

• desempenho (devido ao uso de um cache)
• escalabilidade
• comunicação transparente
• interfaces simples
• portabilidade
• capacidade de fazer mudanças facilmente
• capacidade de evoluir e adaptar-se a novos requisitos

Visão geral do REST. Parte 2: Comunicação entre um cliente e um servidor Visão geral do REST. Parte 3: Construindo um serviço RESTful no Spring Boot