BSI UFRPE PPD - Artigo Rest

Prévia do material em texto

Representational State Transfer (REST) e a evolução da arquitetura de software na 
WEB: descrição e aplicabilidade – Johann Gomes et al 1
A abordagem Representational State Transfer (REST) para 
comunicação entre aplicações WEB
Johann G. Barros1, Josino R. Neto1
1Departamento de Informática – Universidade Federal Rural de Pernambuco (UFRPE)
Caixa Postal 15.064 – 91.501-970 – Recife – PE – Brasil
{johanngomes,josinon}@gmail.com
Abstract. This article describes the technique of software architecture known 
as Representational State Transfer (REST), created with the purpose of 
simplifying communication between networked applications. It explained its 
theoretical foundation, contextualization, applicability and modeling, 
comparing their representation of communication with the traditionally 
observed on the WEB.
Resumo. Este artigo descreve a técnica de arquitetura de software conhecida 
como Representational State Transfer (REST), criada com o propósito de 
simplificar a comunicação entre aplicações em rede. É explanada a sua 
fundamentação teórica, contextualização, aplicabilidade e modelagem, 
comparando sua representação de comunicação com as tradicionalmente 
observadas na WEB.
1. Introdução
Desde que a web surgiu no início da década de 1990 — criada por Tim 
Berners-Lee nos laboratórios do European Organization for Nuclear Research (CERN) 
na Suíça, como apenas uma proposta de gerenciador de informações [9] — até hoje, 
acompanhamos seu aumento de abrangência e complexidade.
Ao longo dos anos, por um lado o conteúdo da web se tornou mais rico e 
multimídia com a introdução de imagem, animações, áudio e vídeo etc. Por outro, sua 
interatividade cresce em ritmo acelerado, tornando a web um canal de interação, 
aplicações e serviços cada vez mais amplo [1]. 
As aplicações na web deram os primeiros passos com o protocolo Common 
Gateway Interface (CGI) até chegarem à era atual dos Web Services (WS), da 
Arquitetura Orientada a Serviços (Service-Oriented Architecture – SOA) e seu uso nos 
sistemas de Gerenciamento de Processos de Negócio (Business Process Management – 
BPM).
Assim, a web deixa de ser a camada de mais alto nível de abstração na pilha das 
aplicações Internet (WWW HTTP TCP/IP). Acima dela se posicionam sistemas→ → 
complexos que tem a web como “mera” base de infraestrutura. Neste topo entram 
princípios e mecanismos como frameworks de aplicações web, AJAX, Web Services e 
REST [2].
Representational State Transfer (REST) e a evolução da arquitetura de software na 
WEB: descrição e aplicabilidade – Johann Gomes et al 2
2. Fundamentação teórica
Web Service é uma solução arquitetural utilizada na integração de sistemas e na 
comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas 
aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos 
em plataformas diferentes sejam compatíveis [3].
REST é uma variante de Web Service, e logo, uma forma de manipular recursos, 
cuja implementação permite flexibilidade nas suas requisições e impõe uma 
padronização ao processo, já que diante de muitas abordagens diferentes, e sem padrão 
algum, era difícil vender middleware [3].
REST é uma abreviação para Representational State Transfer (por vezes 
chamamos de “ReST”). Fundamenta-se em um protocolo de comunicação cacheável, 
cliente-servidor e “stateless” – virtualmente em todos os casos, o protocolo HTTP é 
usado. 
REST possui um estilo de arquitetura projetado para desenhar aplicações WEB. 
A sua ideia fundamental é que, em vez de usar complexos mecanismos como CORBA, 
RPC ou SOAP para conectar duas máquinas, HTTP simples é usado para fazer essa 
comunicação. [6]
REST envolve na maioria das vezes ler uma página WEB que contém um 
arquivo XML. O XML descreve e inclui o conteúdo desejado.
Frequentemente o usamos em aplicações móveis, sites de rede social, 
ferramentas de mashup e processos de negócio automatizados. O estilo REST enfatiza 
que as interações entre clientes e serviços devem possuir um número limitado de 
operações possíveis (verbos). A flexibilidade é provida nomeando recursos (nomes) 
com seus próprios indicadores universais de recurso (URIs). Devido ao fato de cada 
verbo possuir seu significado próprio (GET, POST, PUT e DELETE), o REST escapa 
da ambiguidade [7]. 
Como descrito em uma dissertação de Roy Fielding e Richard Taylor, os dois 
pesquisadores que idealizaram os conceitos do REST, ele pode ser descrito como um 
“estilo arquitetural” que basicamente estende tecnologias já existentes e protocolos da 
WEB, incluindo o HTTP e XML. REST é mais simples de usar do que as conhecidas 
SOAP (Simple Object Access Protocol), que requere a escrita ou o uso de um programa 
servidor provido (para disponibilizar dados) ou um programa cliente (para requisitar 
dados) [8].
3. Aplicabilidade
O uso de REST é aplicável em aplicações web distribuídas, que precisam 
compartilhar recursos entre si, produzidos por uma e consumidos por outra, como por 
exemplo, produzidas por um servidor e consumidas por uma aplicação cliente, 
estabelecendo uma forma de comunicação padrão com esse servidor pelo cliente.
REST elimina a pluralidade de protocolos e diferentes abordagens de segurança, 
padronizando tudo e, logo, diminuindo a complexidade das implementações. Essa 
arquitetura permite mais poder e flexibilidade e menos overhead de protocolo.
Entretanto, não é aplicável o uso dessa arquitetura para requisições quando 
WS-Transaction ou WS-Security fizerem sentido [3], o primeiro é um protocolo usado 
Representational State Transfer (REST) e a evolução da arquitetura de software na 
WEB: descrição e aplicabilidade – Johann Gomes et al 3
para interoperabilidade de recursos envolvendo Data Warehouse ou um conjunto 
específico de dados que precise de uma transação, o segundo deve ser usado quando 
precisamos prover segurança nas nossas requisições, mantendo a integridade e 
confidencialidade dos dados. Quando não houver API HTTP razoável também 
recomenda-se a desconsideração do REST [3], já que ele depende intrinsecamente desse 
protocolo de comunicação.
Quanto à performance, é observado que a arquitetura REST faz com que a 
aplicação ganhe em performance quando comparado com o Web Service SOAP por 
exemplo, entretanto, o ganho é pouco significativo, não justificando o uso de REST 
apenas para ganhos de performance [10].
Figura 1. O gráfico acima foi gerado a partir de uma bateria de testes em duas 
implementações de servidor, uma em REST e outra em SOAP de uma mesma 
aplicação que tratava de problemas de geolocalização [10]
4. Modelando uma aplicação REST
Uma aplicação REST pode ser composta de pelo menos duas aplicações, sendo 
uma delas responsável por se comportar como o servidor e a outra responsável por ser o 
cliente. O funcionamento é semelhante ao de uma requisição a uma página web, temos 
uma aplicação do lado cliente, rodando em uma máquina, que fará requisições a uma 
outra aplicação que poderá rodar em qualquer lugar e que fará as vezes do servidor. 
A diferença é que o REST estabelece um padrão de escrita para essas 
requisições, dando a elas um formato inteligível ao ser humano [5], com uma simples 
leitura do endereço, é possível identificar que recurso se deseja, devido à atribuição de 
um id a elas, vejamos alguns exemplos:
http://example.com/customers/1234
http://example.com/orders/2007/10/776654
http://example.com/products/4554
Representational State Transfer (REST) e a evolução da arquitetura de software na 
WEB: descrição e aplicabilidade – Johann Gomes et al 4
Umdesign desse tipo facilitará o reúso e o entendimento aos usuários de como 
sua aplicação lida com as requisições, já que estamos seguindo um padrão, facilitando a 
comunicação da sua aplicação com o mundo. Devido a esse fato, muitas aplicações web 
famosas que dependem de requisições dos usuários estão adotando o padrão REST, para 
facilitar o uso dessas aplicações por usuários e por desenvolvedores que sejem usar suas 
APIs, como o Facebook (Open Graph API), Twitter, WhatsApp, entre outras redes 
sociais.
No REST temos uma única interface para nos comunicarmos com as aplicações 
web no geral. Por que isso é bom? Vamos supor um cenário de um sistema de compras:
Figura 2. Cenário de um sistema de compras, usando uma interface única para 
cada serviço, como observado tradicionalmente em muitas formas de 
arquitetura de sistemas.
Há dois serviços envolvidos: um gerenciador de clientes e um gerenciador de 
serviços, e a interface para comunicação com eles é específico para cada um dos 
serviços, precisamos conhecer como eles funcionam e quais são o nome dos seus 
métodos para interagirmos com elas. É necessário, então, codificar sobre essas 
interfaces específicas.
Logo, e necessário conhecer cada uma das duas interfaces antes de interagir com 
elas, suas especificidades e peculiaridades.
Representational State Transfer (REST) e a evolução da arquitetura de software na 
WEB: descrição e aplicabilidade – Johann Gomes et al 5
Em uma abordagem de arquitetura REST, temos uma interface genérica para 
todo o protocolo HTTP do aplicativo, exemplo:
 
Figura 3. Cenário de um sistema de compras usando uma interface genérica REST
Uma arquitetura de requisições que segue o padrão REST é chamada RESTful, 
uma aplicação que usa essa arquitetura se utiliza de requisições HTTP para submeter 
dados (criar ou atualizar), ler dados (exemplo: fazer queries) e deletar dados. REST usa 
requisições HTTP para todos os quatro elementos do CRUD 
(Criar/Ler/Atualizar/Deletar) [6]. 
5. Tópicos de pesquisa
Alguns dos tópicos de pesquisa que envolvem os campos de estudo sobre REST 
são:
• Web Services
• Projeto de Sistemas Web
• Software como Serviço (SaaS)
• Protocolo HTTP
Representational State Transfer (REST) e a evolução da arquitetura de software na 
WEB: descrição e aplicabilidade – Johann Gomes et al 6
6. Conclusão
 Porque seguir essa arquitetura padrão REST é importante? Essencialmente, 
seguir essa arquitetura faz seu aplicativo ser parte da WEB - sua contribuição para a 
WEB é proporcional ao número de recursos que sua aplicação adiciona a ela. 
Em uma abordagem RESTful, um aplicativo pode adicionar alguns milhões de 
URIs de clientes na WEB; Se for concebido da mesma forma que os aplicativos dos 
tempos do CORBA, essa contribuição é frequentemente muito pequena – podendo essa 
contribuição ser comparada a uma porta muita pequena que ofereça a entrada para um 
universo de recursos apenas para aqueles que têm a chave, ou seja, aos que entendem o 
funcionamento da aplicação e sua interface.
O uso de uma interface uniforme e generalizada ás aplicações como REST 
também permite que qualquer componente que entenda o protocolo de aplicação HTTP 
interaja com seu aplicativo. Exemplos de componentes que são beneficiados por isso 
são clientes genéricos como o curl, o wget, proxies, caches, servidores HTTP, gateways 
e até mesmo o Google, o Yahoo!, o MSN e muitos outros.
Resumindo, para aumentar a possibilidade de que um grande número de clientes 
possa interagir com os recursos do seu aplicativo, ele deve implementar o protocolo de 
aplicação padrão (HTTP) corretamente, isto é, utilizar os métodos padrão: GET, PUT, 
POST e DELETE.
Portanto, se o seu objetivo for disponibilizar recursos de sua aplicação para que 
eles sejam usados em outras aplicações ou por outros usuários, a abordagem REST é 
bastante interessante, pois ela simplifica essa comunicação.
Representational State Transfer (REST) e a evolução da arquitetura de software na 
WEB: descrição e aplicabilidade – Johann Gomes et al 7
 7. Referências
[1] Ávila, M. (2007) “REST e a evolução da arquitetura de software”, 
http://blog.mhavila.com.br/2007/07/07/rest-e-a-evolucao-da-arquitetura-de-software/
, Jully.
[2] Evans, M. (2008) “The Evolution of the Web From Web 1.0 to Web 4.0”, 
http://www.cscan.org/presentations/08-11-06-MikeEvans-Web.pdf, November.
[3] Pereira, B. (2012) “Web Services REST”, 
http://www.slideshare.net/blpsilva/web-services-rest-presentation, August.
[4] W3C (2004) “Web Services Glossary”, 
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice, November.
[5] Tilkov, S. (2008) “Uma rápida Introdução ao REST”, 
http://www.infoq.com/br/articles/rest-introduction, October.
[6] Elksten, M. (2008) “What is REST?”,
http://rest.elkstein.org/2008/02/what-is-rest.html, February
[7] Rouse, M. (2005) “Definition: REST (representational state transfer)”,
http://searchsoa.techtarget.com/definition/REST, September
[8] Fielding, R. T.; Taylor, R. N. (2000) “Principled design of the modern Web 
architecture”,
http://dl.acm.org/citation.cfm?doid=337180.337228, January
[9] Lee, T. B. (1989) “Information Management: A Proposal”, 
http://www.w3.org/History/1989/proposal.html, March
[10] Bigolin, M. (2012) “ REST X SOAP: análise e implementação de web services”,
http://saloon.inf.ufrgs.br/twiki-data/Disciplinas/CMP167/TF12MarcioBigolin/Textof
inal.pdf, Jully
	1. Introdução
	2. Fundamentação teórica
	3. Aplicabilidade
	4. Modelando uma aplicação REST
	5. Tópicos de pesquisa
	6. Conclusão