Condições Norteadoras de REST

Trabalhando em conjunto com os quatro elementos apresentados na seção anterior um web service, para ser considerado aderente ao estilo arquitetural REST deve atender às seguintes condições (RICHARDSON; RUBY, 2007):

 ser endereçável – o endereçamento trata da exposição do conjunto de características de um recurso através de uma URI. A característica de uma aplicação endereçável possibilita que outros clientes ou aplicações façam a utilização das representações desses recursos (GRÜNER; PALM, 2015). Para que isso aconteça, a aplicação precisa dividir os dados em um conjunto de recursos e, por sua vez, em representações;

 ser encadeado – condição oferecida à uma aplicação por meio dos links enviados na resposta das representações. O cliente, na utilização de uma aplicação bem encadeada, percorre um caminho de recursos sendo guiado através de links bem definidos. Fielding (2000) define o encadeamento tratando a hipermídia como motor de estado da aplicação. Nesse caso, links e formulários demonstram os mecanismos de estados responsáveis pela alteração do estado do recurso (RICHARDSON; RUBY, 2007);

 utilizar interface uniforme – define como os recursos são acessados e as operações básicas que podem ser realizadas sobre eles. Essa uniformização impõe uma padronização, utilizando um conjunto fixo e largamente utilizado das primitivas Create, Read, Update and Delete – Criar, Ler, Atualizar e Deletar (CRUD), na comunicação entres os componentes de uma aplicação REST (OH; KIM, 2014). Nesse ponto, cabe um adendo: a diferença entre recursos está intrínseca nas representações e não na sua interface uniforme. Novamente valendo-se do protocolo HTTP como mediador de interações entre clientes e recursos, REST dispõe de métodos básicos para expor suas funcionalidades (OVERDICK, 2007; PAUTASSO, 2009; LI, 2011; DUGGAN, 2012):

 GET – uma requisição para recuperação/leitura da representação do estado

atual de um recurso. Como a requisição GET não altera o estado atual do recurso, a ela cabe a possibilidade de ser armazenada em cache;

 PUT – operação que trata da criação/atualização completa de um recurso. Se

o recurso informado previamente na representação da URI não existir ele é criado; caso contrário, é atualizado;

 POST – requisição que tem por objetivo a criação (adição) de um recurso

baseado em outro preexistente. É através da requisição POST que pode ser utilizada a capacidade de anexar algo ao estado de um recurso existente sem precisar criar um novo recurso;

 DELETE – operação utilizada para definir que a representação de um

recurso, identificado através de uma URI, não deve mais existir. Cabe salientar que a operação DELETE, assim como PUT, é tratada de forma idempotente; ou seja, executar mais de uma vez uma representação através dessas operações deve ter o mesmo efeito de executá-la apenas uma vez, não

afetando o estado do recurso. O único efeito para o DELETE será na posterior resposta negativa do método GET pois sua URI foi invalidada;

 HEAD – similar a uma requisição GET, diferenciando-se pelo fato de que

somente os metadados da representação são enviados, omitindo-se a representação em si;

 OPTIONS – é um método utilizado para descobrir qual o conjunto de interfaces uniformes (operações básicas) são suportados pelos recursos. Essa

operação é pouco utilizada pelo fato de existirem mecanismos de documentação como arquivos eXtensible Hypertext Markup Language (XHTML) ou WADL;

 não ter estado – conforme citado anteriormente REST faz uso de tecnologias como HTTP, que por padrão é um protocolo sem estado, incorrendo que toda solicitação ocorre em um isolamento completo e nenhuma informação do cliente (sessões por exemplo) é armazenada no servidor (TANENBAUM; STEEN, 2006; RICHARDSON; RUBY, 2007). Para que isso ocorra a solicitação deve conter todos os dados necessários (através de URI, cabeçalhos ou corpo do pedido) para ser compreendida e atendida pelo servidor. Em uma aplicação REST o lado servidor não preserva qualquer estado da aplicação. Cabe salientar aqui uma diferença entre estado da aplicação e estado do recurso. O estado do recurso fica armazenado no servidor e é enviado ao cliente, a cada requisição, através de representações (dados dos recursos). Já o estado da aplicação fica no lado do cliente, sendo o endereço acessado por ele e utilizado para realizar alguma ação sobre um recurso, tornando os pedidos e as respostas autossuficientes (NUNES et al., 2015). Essa característica permite que mecanismos simples de sincronismo de dados entre os componentes da arquitetura possam ser utilizados para resolver problemas complexos de balanceamento de carga. O fato de uma aplicação REST não manter o estado da aplicação simplifica a comunicação assíncrona e o envio de solicitações isoladas em paralelo (GRÜNER; PALM, 2015). Esse fato pode se tornar um ponto positivo e negativo ao mesmo tempo, visto que o desempenho da rede pode ser degradado pelo aumento do número de pequenas requisições.

 utilizar cache – como a arquitetura de uma aplicação REST é distribuída em camadas que se comunicam diretamente apenas com a camada adjacente

(podendo ser composta por elementos físicos intermediários como proxies,

gateways, servidores ou mesmo o próprio equipamento do requisitante) o cliente

não tem a capacidade de diferenciar se está conectado com uma representação final do recurso ou com um intermediário (POLÔNIA; MELGAREJO; QUEIROZ, 2015). Diante dessa característica um equipamento, tanto do lado do cliente ou do servidor, inserido neste meio, pode fazer um uso eficiente da rede realizando cache das respostas e, por sua vez, eliminando algumas interações durante a comunicação (SANTOS, C. et al., 2015). Contudo, existe um tradeoff (conflito de escolha) na utilização de caches: se esse mecanismo não for bem controlado, representações antigas de recursos armazenados podem ser apresentadas aos clientes, diminuindo a confiabilidade; entretanto, seu uso aumenta a escalabilidade e o desempenho;

A figura 7 possibilita a visualização de uma aplicação REST composta dos elementos e das condições que a orientam. Nela é analisada primeiramente a topologia do sistema que é composta por: uma aplicação hospedada em um cliente, um balanceador de carga, servidores proxies que gerenciam o cache das requisições oriundas dos clientes e um servidor web (repositorio.com) que se torna o elemento responsável por hospedar e gerenciar os recursos de um repositório que, neste exemplo, é composto de livros e revistas.

Iniciando-se do cliente tem-se o conceito da interface uniforme, através do método HTTP GET que possibilita a realização de uma solicitação de busca ao resumo do livro identificado pelo número 10. O identificador é enviado através do URI que endereça a aplicação (http://repositorio.com/livro/10/resumo) e não infringe a privacidade do recurso. Cabe aqui citar dois pontos sobre a solução: a utilização do protocolo HTTP que por padrão é um protocolo sem estado, e salientar que a aplicação do cliente não armazena nenhum registro (sessão) das requisições no lado do servidor. Orientando-se por esses dois pontos pode-se realizar facilmente o balanceamento de carga e o cache das requisições em servidores proxy sincronizando somente o estado do recurso (representação). Utilizando-se do conceito de recurso e representação, temos o livro como recurso e seu resumo atual como a representação que o sintetiza. Nesse mesmo servidor tem-se hospedado outro recurso (revistas) e, por conseguinte, sua representação que é uma listagem (links) com as notícias de determinada revista. Regressando ao livro e ao seu resumo, o tipo de dado retornado para a solicitação

GET é apresentado no formato JSON e é analisado no texto da figura que contém a resposta

Figura 7 – Elementos e condições de uma aplicação REST.

Fonte: Elaborada pelo autor.