Olá, hoje estudaremos um tema muito interessante e, o mais importante, muito procurado no mercado de trabalho - REST. Dividiremos a visão geral do REST em três partes:
Na primeira parte, abordaremos a história do REST e descreveremos os princípios nos quais o REST se baseia.
Na segunda, veremos como ocorre a comunicação entre o cliente e o servidor através do protocolo HTTP.
Na terceira, escreveremos uma pequena aplicação RESTful, que testaremos utilizando o programa Postman.
O artigo destina-se a um leitor familiarizado 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 muitas coisas no mundo da TI, é um acrônimo para Representational State Transfer . Este é um estilo arquitetônico de interação entre componentes de sistemas distribuídos em uma rede de computadores. Simplificando, REST define um estilo de interação (troca de dados) entre diferentes componentes de um sistema, cada um dos quais pode estar fisicamente localizado em locais diferentes. Este estilo arquitetônico representa um conjunto consistente de restrições que são consideradas ao projetar um sistema distribuído. Essas restrições às vezes são chamadas de princípios REST. Não são muitos, apenas 6 peças. Falaremos sobre eles um pouco mais tarde.
Aplicativos desenvolvidos com REST em mente, ou seja, que não violam as restrições impostas pelo REST são chamados de RESTful.
História do REST
O termo REST foi cunhado por Roy Fielding, um dos criadores do protocolo HTTP, em sua tese de doutorado "Estilos Arquitetônicos e Design de Arquiteturas de Software Baseadas em Rede" em 2000. Podemos dizer que o termo REST ainda é jovem, embora seu conceito esteja na base da World Wide Web. Não nos aprofundaremos na história da origem deste termo. Se você quiser se aprofundar nas fontes originais, dê uma olhada na dissertação de Fielding .
Restrições e princípios REST
Conforme afirmado acima, REST define como os componentes de um sistema distribuído devem interagir entre si. Em geral, isso acontece por meio de solicitação-resposta. O componente que envia a solicitação é chamado de cliente ; O componente que processa a solicitação e envia uma resposta ao cliente é chamado de servidor . Solicitações e respostas são geralmente enviadas via HTTP (HyperText Transfer Protocol). Normalmente, um servidor é algum tipo de aplicativo da web. O cliente pode não ser qualquer coisa, mas bastante. Por exemplo, um aplicativo móvel que solicita dados do servidor. Ou um navegador que envia solicitações de uma página da web a um servidor para baixar dados. O aplicativo A pode solicitar dados do aplicativo B. Então 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 C, D, D, etc. Nesse caso, o aplicativo A é um servidor e um cliente. Tudo depende do contexto. Uma coisa é certa: o componente que envia a solicitação é o cliente. O componente que recebe, processa e responde à solicitação é o servidor. No entanto, nem todo sistema cujos componentes se comunicam via solicitação-resposta é um sistema REST (ou RESTful). Para que um sistema seja considerado RESTful, ele deve “ajustar-se” a seis restrições REST:
1. Trazendo a arquitetura para um modelo cliente-servidor
A base desta limitação é a diferenciação de necessidades. É necessário separar as necessidades da interface do cliente das necessidades do servidor que armazena os dados. Esta limitação aumenta a portabilidade do código do cliente para outras plataformas, e a simplificação da parte do servidor melhora a escalabilidade do sistema. A própria distinção entre “cliente” e “servidor” permite que eles se desenvolvam independentemente um do outro.
2. Falta de condição
A arquitetura REST requer que a seguinte condição seja atendida. Entre as solicitações, o servidor não precisa armazenar informações sobre o estado do cliente e vice-versa. Todas as solicitações do cliente devem ser estruturadas para que o servidor receba todas as informações necessárias para concluir a solicitação. Desta forma, tanto o servidor quanto o cliente podem “entender” qualquer mensagem recebida sem depender de mensagens anteriores.
3. Cache
Os clientes podem armazenar em cache as respostas do servidor. Estes, por sua vez, devem ser designados explícita ou implicitamente como armazenáveis em cache ou não armazenáveis em cache, para que os clientes não recebam dados obsoletos ou incorretos em resposta a solicitações subsequentes. O uso adequado do cache ajuda a eliminar algumas interações cliente-servidor, total ou parcialmente, aumentando ainda mais o desempenho e a extensibilidade do sistema.
4. Uniformidade da interface
Os requisitos fundamentais da arquitetura REST incluem uma interface unificada e consistente. O cliente deve sempre entender em que formato e para quais endereços precisa enviar uma solicitação, e o servidor, por sua vez, também deve entender em que formato deve responder às solicitações do cliente. Este é um formato unificado para interação cliente-servidor, que descreve o que, onde, de que forma e como enviar e é uma interface unificada
5. Camadas
Camadas referem-se à estrutura hierárquica das redes. Às vezes, o cliente pode se comunicar diretamente com o servidor e, às vezes, simplesmente se comunicar com um nó intermediário. O uso de servidores intermediários pode aumentar a escalabilidade por meio de balanceamento de carga e cache distribuído. Vamos dar um exemplo. Vamos imaginar um aplicativo móvel popular em todo o mundo. Sua parte integrante é o carregamento de imagens. Como existem milhões de usuários, um servidor não suportaria uma carga tão pesada. Dividir o sistema em camadas resolverá esse problema. O cliente solicitará uma imagem do nó intermediário, o nó intermediário solicitará a imagem do servidor que está menos carregado no momento e retornará a imagem ao cliente. Se o cache for aplicado corretamente aqui em cada nível da hierarquia, então uma boa escalabilidade do sistema poderá ser alcançada.
6. Código sob demanda (restrição opcional)
Esta limitação implica que o cliente pode expandir sua funcionalidade baixando código do servidor na forma de miniaplicativos ou scripts.
Os benefícios do REST
As aplicações que atendem a todas as restrições acima apresentam as seguintes vantagens: confiabilidade (não há necessidade de armazenar informações de estado do cliente, que podem ser perdidas);
desempenho (devido ao uso de cache);
escalabilidade;
transparência do sistema de interação;
simplicidade de interfaces;
portabilidade de componentes;
facilidade de fazer alterações;
a capacidade de evoluir, adaptando-se às novas exigências.
GO TO FULL VERSION