REST – A Base da Arquitetura

A base da arquitetura ROA é fundamentada nos princípios de REST. REST, por sua vez, não é uma arquitetura ou um padrão nos mesmos moldes de SOAP, e pode ser definido com um estilo arquitetural, desenvolvido por Roy Fielding em sua tese de doutorado (FIELDING, 2000) como um modelo abstrato da arquitetura web para orientar a reformulação e definição do Hypertext Transfer Protocol (HTTP) e dos URIs baseado em um conjunto de critérios para o desenvolvimento de aplicações em rede. Esse estilo consiste em várias restrições para tratar da divisão de interesses, visibilidade, confiabilidade, escalabilidade, flexibilidade e desempenho. Embora REST não possa ser tratado como um padrão de fato, com a finalidade de definir seu comportamento e boas práticas, no intuito de transformar um problema em um recurso, ele faz uso de padrões estabelecidos e difundidos no desenvolvimento de aplicações web distribuídas, tais como HTTP, URIs, XML, JavaScript Object Notation (JSON), HTML, dentre outros (BELQASMI et al., 2012; DUGGAN, 2012; NUNES et al., 2015). Para Li (2011) REST não é um protocolo e sim uma descrição de como desenvolver um sistema distribuído, frente as suas dificuldades, utilizando-se ao máximo dos recursos básicos da web.

O conceito que torna REST um estilo arquitetural e que possibilita o desenvolvimento de aplicações distribuídas também é analisado em Santos, C. et al. (2015). Os autores destacam que a principal característica de REST é envolver clientes e servidores através do envio e recebimento de mensagens de uma forma que não fossem impostas restrições sobre o seu formato, mas sim sobre o comportamento dos elementos envolvidos.

O estilo REST não restringe a comunicação entre cliente e servidor a um protocolo específico; contudo, o protocolo comumente utilizado é o HTTP para transferência de dados e representações entre web services. Antes de utilizar um recurso, o consumidor precisa encontrá-lo e conhecê-lo. Para a realização dessas tarefas, além do uso de WSDL, comumente utiliza-se de um arquivo Web Application Description Language – Linguagem de Descrição de Aplicação Web

(WADL). O foco de um arquivo WADL está no recurso, que descreve sua finalidade, contendo um identificador URI, os dados que devem ser informados como parâmetros para invocação e o padrão utilizado para resposta. Ao invés de interfaces os recursos descritos nesse arquivo têm uma noção dos métodos HTTP que são aplicados a eles (FOKAEFS; STROULIA, 2015; XUE; ZHANG; JI, 2015).

Segundo Richardson e Ruby (2007) a arquitetura ROA toma por base quatro elementos oriundos de REST:

 recursos – no lugar da definição de serviços exposta por SOA, em ROA tem-se o conceito de recurso. Recursos são utilizados para transformar um problema em um web service REST. Um recurso em ROA é um mapeamento conceitual, onde um servidor recebe um identificador e responde com uma ação. Para Belqasmi et al. (2012) uma definição, em primeiro momento formal e depois voltada à programação é apresentada sobre os recursos dentro de ROA. Os autores referem- se a um recurso como qualquer forma de informação que seja importante o suficiente para ser referenciado como um documento, uma linha em um banco de dados ou o resultado de uma pesquisa. Uma visão mais genérica é apresentada por Ambra et al. (2013) e Polônia, Melgarejo e Queiroz (2015) onde os recursos são tratados como uma informação abstrata de uma entidade que possa ser mapeada e identificada. Recursos não são os dados em si, são apenas uma ideia de como os dados de web services serão divididos podendo ser apresentados de forma estática ou com alguma variação;

 representações – as representações expõem o estado atual ou desejado de um recurso partindo do princípio que os recursos são os dados conceituais em si. Se o estado atual de um recurso for um dado, as representações apresentam a sua estrutura semântica (metadados) e seu conteúdo. Cabe salientar que as representações não estão vinculadas a qualquer tipo de dado em particular, podendo ser utilizado qualquer formato para representar um recurso (arquivos HTML, XML, JSON, imagens ou vídeos, por exemplo), e sua utilização oculta do cliente aspectos internos desses recursos. Com o objetivo de facilitar o entendimento Haupt et al. (2014) cita o exemplo de um blog na internet que utiliza REST. Um artigo desse blog é o recurso disponível e o cliente, ao acessar esse artigo, abre uma representação HTML do recurso (artigo). Utilizando dessa premissa um recurso pode ter múltiplas representações e os clientes podem

escolher quais representações se adaptam à sua realidade através de mecanismos de múltiplo acesso. Esse múltiplo acesso pode ser alcançado de duas formas: nomeando e acessando recursos através de identificadores únicos (diferentes URIs) ou por meio de negociação de conteúdo – por exemplo, através de atributos de cabeçalho da solicitação HTTP (POLÔNIA; MELGAREJO; QUEIROZ, 2015);

 nomes – a URI é o nome e o endereço de um recurso. Sua utilização é fundamental e se ignorada não possibilita a visibilidade e utilização de um recurso. A URI é responsável por fazer referência a um recurso e também por manter a validade semântica do mapeamento ao longo do tempo. As URIs necessitam ser correspondências claras de um recurso e devem direcionar a apenas um recurso; entretanto, várias URIs podem designar um único recurso possibilitando várias formas de acesso ao mesmo aumentando sua visibilidade;

 links (hypermedia relationships) – é através dos links que são fornecidos acessos

a outros recursos, bem como a sua correlação. Um exemplo clássico da utilização de links é a pesquisa em um site de busca que faz o uso dos conceitos de REST. Após uma consulta, o site retorna os dados (representações de um determinado recurso pesquisado) fornecendo ligações para essas representações. Os links podem qualificar o estado interno de um recurso permitindo a suposição sobre o seu comportamento (OVERDICK, 2007).