Ricardo Ghisi Tobaldini

Arquitetura REST: um estudo de sua implementao em linguagens de programao

Florianpolis SC 2007/2

Ricardo Ghisi Tobaldini

Arquitetura REST: um estudo de sua implementao em linguagens de programaoTrabalho de concluso de curso apresentado como parte dos requisitos para obteno do grau de Bacharel em Cincias da Computao.

Orientador:

Luiz Fernando Bier Melgarejo

BACHARELADO EM C INCIAS DA C OMPUTAO D EPARTAMENTO DE I NFORMTICA E E STATSTICA C ENTRO T ECNOLGICO U NIVERSIDADE F EDERAL DE S ANTA C ATARINA

Florianpolis SC 2007/2

Arquitetura REST: um estudo de sua implementao em linguagens de programao

Trabalho de concluso de curso apresentado como parte dos requisitos para obteno do grau de Bacharel em Cincias da Computao.

Prof. Luiz Fernando Bier Melgarejo Orientador

Banca Examinadora

Prof. Dr. Rosvelter Coelho da Costa

Prof. Dr. Jos Mazzucco Jr.

A atividade da engenharia, enquanto permanecer atividade, pode levar a criatividade do homem a seu grau mximo; mas, assim que o construtor pra de construir e se entrincheira nas coisas que fez, as energias criativas se congelam, e o palcio se transforma em tumba. Marshall Berman

Sumrio

Lista de Figuras Lista de Tabelas 1 Introduo 1.1 1.2 2 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivo Especco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 8 p. 8 p. 9 p. 10 p. 10 p. 11 p. 11 p. 11 p. 12 p. 12 p. 13 p. 13 p. 14 p. 14 p. 14 p. 15 p. 15

Arquitetura de Software 2.1 Estilos Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6 2.1.7 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cliente-Servidor Sem Estado . . . . . . . . . . . . . . . . . . . . . . Cliente com Cache-Servidor sem Estado . . . . . . . . . . . . . . . . Sistema em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . Cdigo sob Demanda . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

REST 3.1 Compondo o REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sem Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.4 3.1.5 3.1.6 3.2

Cdigo sob Demanda . . . . . . . . . . . . . . . . . . . . . . . . . . Sistema em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . Interface Uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . .

p. 16 p. 16 p. 16 p. 17 p. 17 p. 19 p. 21 p. 22 p. 22 p. 23 p. 24 p. 24 p. 26

Elementos Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 Elementos de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . Conectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Web - Uma Aplicao REST 4.1 4.2 Localizao de Recursos Atravs de URI . . . . . . . . . . . . . . . . . . . . HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 4.2.2 Mtodo GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mtodo POST . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Referncias Bibliogrcas

Lista de Figuras1 2 3 4 Estilo Arquitetural Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . Estilo Arquitetural Cliente-Servidor sem Estado . . . . . . . . . . . . . . . . Estilo Arquitetural Cliente com Cache-Servidor sem Estado . . . . . . . . . . Exemplo de URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14 p. 15 p. 15 p. 22

Lista de Tabelas1 2 Conectores REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Componentes do REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19 p. 21

8

1

Introduo

Dijsktra, desde 1968, mostrou como o particionamento e a estruturao de software importante e no meramente programando uma soluo apenas "correta"do problema. Ele introduziu a idia de estruturas em camadas para sistemas operacionais, resultando em maior facilidade no desenvolvimento e manuteno. Com o tamanho e complexidade dos sistemas aumentando cada vez mais os problemas de um sistema vo alm dos algortmos e estruturas de dados. A especicao e o projeto do sistema nasce como um novo tipo de problema. Os problemas estruturais de um projeto encluem protocolos de comunicao, distribuio fsica, composio de elementos, escala e performance, estruturas de controle e organizao. Estes tipos de problemas so tratados atravs do uso de arquiteturas de software. Engenheiros de software utilizam principios arquiteturais para projetar sistemas complexos. Muitos destes princpios representam regras ou padres idiomticos que surgiram informalmente com o tempo. Outros foram mais cuidadosamente documentatos como padres cientcos e industriais. Neste trabalho ser abordado o estilo arquitetural REST, proposto por Roy Fielding em sua dissertao de doutorado chamada Architectural Styles and the Design of Network-based Software Architectures, assim como um exemplo de aplicao que se vale deste estilo arquitetural, a Web, alm da anlise de frameworks para implementao de aplicaes REST disponveis nas linguagens mais utilizadas atualmente na Web

1.1

Objetivo Geral

Conhecer a arquitetura REST, analisar a Web como uma aplicao que segue os princpios arquiteturais de REST e analizar frameworks disponveis para implementao de sistemas Web utilizando esta arquitetura.

9

1.2

Objetivo Especco

Conhecer a arquitetura REST; Analisar a Web como uma aplicao REST; Analisar frameworks para implementao de REST.

10

2

Arquitetura de Software

A arquitetura de software de um programa ou um sistema computacional a estrutura ou as estruturas do sistema, que constituem componentes de software, as propriedades externamente visveis destes componentes, e a relao entre eles. [1]

A arquitetura de software baseada no princpio da abstrao. Abstrai-se detalhes de um sistema de forma a identicar melhor suas propriedades, desta forma um sistema complexo pode ter vrios nveis de abstrao cada um com sua prpria arquitetura. Uma arquitetura se preocupa exclusivamente com o comportamento e interao entre os diversos elementos que a compem, ignorando detalhes internos especcos de cada um destes elementos. Cada elemento, por sua vez, pode ser composto por outras arquiteturas de forma a atender ao comportamento exigido pela arquitetura do nvel superior (externa a este elemento). Esta seqncia de abstraes pode ser aplicada at que no seja mais possvel decompor um elemento.

2.1

Estilos Arquiteturais

Um estilo arquitetural descreve uma categoria de sistema que engloba diversos aspectos: um conjunto de componentes que exercem uma funo requerida para um sistema (ex: banco de dados); um cojunto de conectores que permitem a comunicao, cooperao e coordenao entre componentes; restries e caractersticas que denem como componentes podem ser integrados; e modelos semnticos que permitem entender as propriedades do sistema como um todo atravs da anlise das propriedades das partes e constituem o sistema.[1] Estilos formam, assim, mecanismos de categorizao de arquiteturas e denio de caractersticas comuns. Cada estilo captura a essncia de um padro de interaes ignorando eventuais detalhes do resto da arquitetura.

11

2.1.1

Cache

Cache um estilo arquitetural de replicao de informaes, sua funcionalidade bsica guardar respostas requisies feitas anteriormente e us-las mais tarde como resposta a novas requisies equivalentes. A replicao pode ser feita ativamente, ou seja, repostas para algumas requisies so obtidas antes mesmo que alguma requisio seja feita, antecipando os resultados. Ou ainda pode ser feita de forma tardia, onde uma resposta somente armazenada quando solicitada pelo menos umas vez.

2.1.2

Cliente-Servidor

O estilo Cliente-Servidor composto de um servidor que fornece uma srie de servios e aguarda por conexes de clientes. Do outro lado o cliente responsvel por saber quais servios necessita e requisit-los a um servidor. O servidor, quando solicitado, envia uma resposta - positiva ou negativa - ao cliente. Neste estilo o servidor geralmente um processo interminvel ou seja, ca aguardando requisies de clientes indenidamente e pode servir mais de um cliente. O princpio fundamental por trs do estilo Cliente-Servidor a separao de responsabilidades. Quando esta separao feita apropriadamente, simplica o componente servidor em favor a escalonabilidade e transfere a responsabilidade de interao com o usurio para o componente do cliente. A separao dos dois componentes permite que cada um se desenvolva independentemente desde que a interface de comunicao entre os dois no seja alterada.

2.1.3

Cliente-Servidor Sem Estado

Ao estilo Cliente-Servidor adiciona-se tambm uma caracterstica de comunicao sem estado. Neste tipo de comunicao cada requisio feita pelo cliente deve conter todas as informaes necessrias para que o servidor possa processar esta requisio sem que ele tenha que armazenar nenhuma informao referente ao estado do cliente. Desta forma todo o estado da sesso entre o cliente e o servidor deve ser conhecido somente pelo cliente. Este princpio traz algumas vantagens como visibilidade, conabilidade e escalonabilidade. A visibilidade melhorada pois necessrio observar apenas uma requisio do cliente para saber o que est acontecendo entre cliente e servidor pelo fato de que toda a informao necessria para isto est embutida na requisio do cliente. Esta caracterstica tambm facilita a tarefa de recuperao de falhas, melhorando a conabilidade. E como o servidor precisa apenas lidar

12

com as requisies atuais do cliente, sem a dependncia de requisies anteriores, a liberao de recursos computacionais se d de forma mais gil melhorando assim a escalonabilidade. Junto com estas vantagens so agregadas algumas desvantagens tambm. Por no armazenar o estado de cada cliente o servidor necessitar a cada requisio vrias informaes adicionais para complet-la, estas informaes podem se tornar repetitivas em uma srie de requisies, aumentando a quantidade de dados trocados atravs da rede e possivelmente diminuir a performance geral da aplicao. Alm disso o armazenamento de estado apenas no cliente transfere grande parte da semntica da aplicao a ele, desta forma o servidor no pode controlar se uma determinada verso do cliente est se comportando da maneira correta ou no.

2.1.4

Cliente com Cache-Servidor sem Estado

Combinando-se os estilos Cliente-Servidor Sem Estado e Cache chega-se ao Cliente com Cache-Servidor Sem Estado. A grande vantagem deste estilo sobre o anterior de poder, parcialmente ou at totalmente, eliminar algumas interaes entre cliente e servidor, sobrecarregando menos o servidor (escalonabilidade), melhorando a performance geral do sistema e diminuindo o tempo de resposta da aplicao. Apesar disto, este sistema pode prejudicar a conabilidade da aplicao. Imagine um cenrio onde um cliente A realiza uma requisio, o servidor responde e o cliente armazena esta resposta em cache. Um outro cliente B, ento, realiza uma transao que modicar o contedo da resposta para a requisies iguais as que o cliente A realizou anteriormente. Se o cliente A repete aquela requisio mais uma vez e utiliza seu cache para aumentar a agilidade da resposta, receber dados inconsistentes.

2.1.5

Sistema em Camadas

Um sistema em camadas permite a uma arquitetura ser composta por diversos nveis hierrquicos, restringindo os componentes participantes de tal forma que nenhum deles possa enxergar atravs da camada com quem est interagindo diretamente, ou seja, o conhecimento do sistema que o componente possui restrito a uma camada apenas. Camadas podem ser usadas para encapsular servios legados, proteger novos servios de clientes legados, melhorar a escalonabilidade atravs da distribuio de carga entre redes e processadores ou para a aplicao de polticas de segurana, fornecendo restries de acessos. Outra funo que uma camada pode exercer a de transformao do contedo das requisies e respostas.

13

A grande desvantagem deste sistema o um maior atraso da chegada da informao de um extremo ao outro por causa dos diversos intermedirios. Para um sistema que suporta as caractersticas de cache esta desvantagem pode ser contornada atravs do compartilhamento de cache entre as camadas permitindo que uma requisio que j foi feita anteriormente possa ser servida atravs de uma camada intermediria ao invs de percorrer todo o caminho at destino nal.

2.1.6

Cdigo sob Demanda

Permite que as funcionalidades do cliente sejam inseridas em tempo de execuo atravs da descarga e execuo de cdigo na forma de applets ou scripts. Esta caracterstica pode facilitar a extenso do sistema mas tambm reduz a visibilidade.

2.1.7

Interface Uniforme

Aplicando o princpio de generalizao de engenharia de software interface dos componentes, a arquitetura simplicada e a visibilidade melhorada. O problema desta uniformizao que toda a troca de informao feita de uma forma genrica ao invs de ser especca para cada necessidade.

14

3

REST

Transferncia de Estado Representacional, REST, um estilo arquitetural hbrido para sistemas hipermdia distribudos derivado dos estilos arquiteturais mostrados no captulo II e combinado com caractersticas adicionais.

3.1

Compondo o REST

A composio de REST se d atravs da agregao de dois outros estilos arquiteturais: Cliente com Cache-Servidor sem Estados com suporte a cdigo sob demanda e separao em camadas; Interface uniforme

3.1.1

Cliente-Servidor

Atravs do uso da arquitetura Cliente-Servidor REST torna possvel que os componentes, o cliente e o servidor, se desenvolvam independentemente pois existe a uma separao de responsabilidades bem denida. A evoluo independente de cada parte torna REST apto a suportar os requerimentos de aplicaes de multiplos domnios organizacionais na escala da Internet.

Figura 1: Estilo Arquitetural Cliente-Servidor

15

3.1.2

Sem Estado

Em REST as comunicaes no devem depender de estados controlados pelo servidor, incorpora-se nesta caracterstica o estilo Cliente-Servidor sem Estado. Desta forma cada requisio feita pelo cliente sempre dever possuir todos os atributos para que ela possa ser processada pelo servidor sem que este ltimo se aproveite de informaes adicionais sobre o contexto da comunicao. Toda informao de estado deve ser conhecida somente pelo cliente.

Figura 2: Estilo Arquitetural Cliente-Servidor sem Estado

3.1.3

Cache

Para melhorar a ecincia da comunicao entre cliente e servidor adiciona-se a REST caractersticas de cache de forma a incorporar o estilo Cliente com Cache-Servidor sem Estado. As caractersticas de cache torna necessria a marcao explcita de uma resposta no mbito de esta ser ou no passvel de cache. Se uma resposta pode se aproveitar das vantagens oferecidas pelo cache ento d-se ao cliente o direito de reusar esta resposta futuramente.

Figura 3: Estilo Arquitetural Cliente com Cache-Servidor sem Estado

16

3.1.4

Cdigo sob Demanda

REST permite que as funcionalidades do cliente sejam inseridas em tempo de execuo atravs da descarga e execuo de cdigo na forma de applets ou scripts. Esta caracterstica pode facilitar a extenso do sistema mas tambm reduz a visibilidade por isso seu uso opcional em REST.

3.1.5

Sistema em Camadas

Um sistema em camadas permite a uma arquitetura ser composta por diversos nveis hierrquicos restringindo os componentes participantes de tal forma que nenhum deles possa enxergar atravs da camada com quem est interagindo diretamente, ou seja, o conhecimento do sistema que o componente possui restrito a uma camada apenas. Camadas podem ser usadas para encapsular servios legados, proteger novos servios de clientes legados, melhorar a escalonabilidade atravs da distribuio de carga entre redes e processadores ou para a aplicao de polticas de segurana fornecendo restries de acessos. Outra funo que uma camada pode exercer a de transformao do contedo das requisies e resposta, REST torna isso possvel pois cada requisio auto-descritiva. A grande desvantagem deste sistema o um maior atraso da chegada da informao de um extremo ao outro por causa dos diversos intermedirios. Para um sistema que suporta as caractersticas de cache esta desvantagem pode ser contornada atravs do compartilhamento de cache entre as camadas permitindo que uma requisio que j foi feita anteriormente possa ser servida atravs de uma camada intermediria ao invs de percorrer todo o caminho at destino nal.

3.1.6

Interface Uniforme

A caracterstica principal que distingue REST de outras arquiteturas baseadas em rede a sua nfase em uma interface uniforme entre componentes.[2] Aplicando o princpio de generalizao de engenharia de software interface dos componentes, a arquitetura simplicada e a visibilidade melhorada. O problema desta uniformizao que toda a troca de informao feita de uma forma genrica ao invs de ser especca para cada necessidade. Porm, REST foi projetado para ser eciente na troca de dados hipermdia no caso comum, a Web.

17

REST denido atravs de quatro elementos de interface: identicao de recursos; manipulao de recursos atravs de representaes; mensagens auto-descritivas; e hipermdia como mquina de estados da aplicao.[2]

3.2

Elementos Arquiteturais

REST ignora detalhes de implementao de componentes e sintaxe de protocolos para se focar nos papis dos componentes, suas interaes e interpretaes de elementos de dados.[2]

3.2.1

Elementos de Dados

A natureza e o estado dos elementos de dados de uma arquitetura so os aspectos chaves do REST. Quando selecionamos uma ligao - na Web por exemplo - a informao necessita ser movida do local onde armazenada para o local onde ela ser processada. Esta caracterstica distinta de muitos outros paradigmas de processamento distribudo, onde possvel - e geralmente mais eciente - mover "o processamento"(em forma de uma expresso de busca ou um programa mvel) at os dados ao invs de levar os dados ao processamento. Um arquiteto de software distribudo tem, fundamentalmente, trs alternativas:[2] processar os dados onde eles esto localizados e enviar a resposposta ao cliente em um formato especco; encapsular os dados e o cdigo de processamento e envi-los ao cliente para que este ltimo o execute; enviar os dados brutos ao cliente juntamente com metainformaes que descrevam os dados, permitindo ao cliente escolher e utilizar a processamento que lhe for conveniente. Cada abordagem tem suas vantagens e desvantagens. A primeira opo - o estilo clienteservidor tradicional - permite que toda informao sobre a natureza dos dados seja de estrito conhecimento do servidor, fazendo com que a implementao do cliente seja simplicada. Entretando toda a responsabilidade de processamento de informaes ca a cargo do servidor, levando a problemas de escalonabilidade. O segundo mtodo prov o processamento especializado ao cliente ao mesmo tempo em que o limita a processar os dados apenas do jeito que foi estipulado pelo servidor. Finalmente, utilizando-se o terceiro mtodo, permite-se que o servidor

18

seja simples e escalonvel ao mesmo tempo em que minimiza a quantidade de dados transferidos, mas perde a vantagem da ocultao de informao e necessita que ambos cliente e servidor entendam o mesmo tipo de dados. REST um hbrido destes trs mtodos, focando-se num entendimento compartilhado dos tipos de dados atravs de metadados, e limitando o escopo do que revelado atravs de uma interface uniforme.[2] No REST os componentes se comunicam atravs da transferncia de representaes de um recurso em um formato selecionado dinamicamente de um conjunto de tipos de dados padres, baseado nas capacidades e desejos do componente que ir receber as informaes e da natureza do recurso. Sejam estas representaes no mesmo formato que os dados brutos ou derivadas destes, isto permanece transparente. Recursos e Identicadores de Recursos A abstrao chave de informao no REST um recurso.[2] Qualquer informao que possa receber um nome pode ser um recurso: um documento, uma imagem, um servio, uma coleo de outros recursos e assim por diante. Em outras palavras, qualquer conceito que possa ser alvo de uma referncia deve se encaixar na denio de recurso. Um recurso R pode ser representado como uma funo de mapeamento temporal Mr (t), onde o tempo t mapeia para um conjunto de entidades, valores ou equivalentes.[2] Um recurso pode ser mapeado para um conjunto vazio, o que permite que referncias sejam feitas a um conceito antes mesmo deste conceito existir. Para identicar um recurso o REST utiliza um identicador de recurso, um exemplo de identicador de recursos a URI1 utilizada na Web. Representaes Uma representao, em REST, uma seqncia de bytes e mais os metadados desta representao, que descrevem aqueles bytes. Exemplos de representaes so: documentos em formato texto, arquivos binrios, mensagens HTTP2 . De forma mais precisa, uma representao consiste de dados, metadados para descrever os dados e, ocasionalmente, outro conjunto de metadados que descrevem os metadados (geralmente utilizado para vericao de integridade da mensagem[2]). Os metadados so apresentados na forma de pares nome-valor, onde o nome corresponde a1 Unied 2 Hypertext

Resource Identier Transfer Protocol

19

um padro que dene a estrutura do valor e sua semntica[2]. Mensagens de respostas podem incluir metadados da representao assim como metadados do recurso (informaes sobre o recurso que no so especcas representao fornecida). Outro elemento participante uma representao so as informaes de controle. As informaes de controle so utilizadas para denir o propsito de uma mensagem entre os componentes ou parametrizar requisies e redenir o comportamento padro de alguns elementos. Por exemplo, o comportamento de um cache pode ser alterado atravs dessas informaes embutidas em uma requisio ou uma resposta. Estas informaes podem ser utilizadas tambm para indicar o estado atual de um recurso solicitado, o estado desejado para um recurso ou a representao de alguma condio de erro para uma resposta. O formato dos dados de uma representao conhecido como tipo de informao. Uma representao pode ser includa em uma mensagem e processada de acordo com os dados de controle e a natureza do tipo de informao. Um tipo de informao pode ser intencionado para processamento automatizado, outros para serem visualizados pelo usurio e outros para ambos.[2] A composio de tipos de informao podem ser utilizadas para incluir mltiplas representaes em uma nica mensagem.

3.2.2

Conectores

REST utiliza vrios tipos de conectores para encapsular a atividade de acesso a recursos e para transferir representaes de recursos. Os conectores provm uma interface abstrata para a comunicao entre componentes, melhorando a simplicidade do sistema atravs da separao de responsabilidades e ocultao da implementao de recursos e mecanismos de comunicao.[2] Conector Exemplos da Web

cliente libwww, libwww-perl servidor libwww, Apache API, NSAPI cache cache do navegador resoluo de nomes bind (biblioteca de resoluo de nomes DNS) tnel SOCKS, HTTP sobre SSL Tabela 1: Conectores REST Similar invocao pocedural, a interface dos conectores permitem a passagem de parmetros e resultados. Parmetros de entrada da requisio consistem em informaes de controle, um identicador de recurso e, opcionalmente, uma representao. Os parmetros de sada so compostos pela informao de controle da resposta, opcionalmente metadados do recurso e uma

20

representao - esta ltima tambm opcional. Os dois primeiros tipos de conectores da tabela 1 - cliente e servidor respectivamente - so os conectores primrios de REST. A diferena essencial entre os dois que cabe ao cliente sempre ter iniciativa sobre o servidor, ou seja, fazer uma requisio, enquanto o servidor deve aguardar passivamente as requisies e atend-las de forma a fornecer acesso aos seus servios. Um componente pode incluir ambos os conectores.[2] O conector cache encontrado no meio, entre um cliente e um servidor, e tem a funo de armazenar respostas passveis de cache para reutilizao em requisies posteriores. Um cache tambm pode ser utilizado no cliente de forma a evitar repeties de comunicaes de rede, ou pelo servidor para diminuir a gerao de respostas. Em ambos os casos o cache contribui para a diminuio do tempo de resposta da aplicao. Tipicamente o cache implementado no domnio do conector que o utiliza. Um cache capaz de determinar se uma reposta ou no passvel de reutilizao pois a interface para cada recurso genrica. Por padro, respostas a requisies de recuperao de informaes so armazenadas em cache enquanto outros tipos de requisio no o devem. Por exemplo uma requisio de alterao de dados relativos a um recurso, esta no deve ser armazenada em cache. A resoluo de nomes converte o nome, de uma URI por exemplo, em um endereo de rede. Atravs deste endereo de rede que possvel iniciar uma conexo com um componente. Este componente pea chave para a existncia de endereos de identicao dos recursos. Finalmente, a ltima pea dos conectores de REST o tnel. Sua funo criar um caminho virtual para travessia de informaes de forma a transpor limites, como um rewall ou um roteador. A nica razo para incluir tnel como parte da arquitetura REST, e no abstrair como parte da infraestrutura de rede, que alguns componentes do REST podem trocar dinamicamente de um comportamento ativo para um comportamento de tnel.[2] Um exemplo deste cenrio quando utiliza-se um proxy 3 HTTP que, dependendo do tipo de requisio que ele intermedia deixa suas funes de proxy e passa a se comportar como um tnel para exercer a comunicao diretamente (sem passagem pelo proxy). Os tneis so destrudos aps o trmino de uma comunicao entre componentes. um tipo de servio que atua nas requisies dos seus clientes executando os pedidos de conexo a outros servidores.3 Proxy

21

3.2.3

Componentes

Os componentes de REST so categorizados pelo papel que exercem no mbito geral de uma aplicao. Abaixo so relacionados os tipos de componentes presentes em REST. Componente servidor de origem gateway proxy agente do usurio Exemplos da Web Servidor HTTP (Apache, Microsoft IIS) Squid, CGI, Proxy reverso CERN Proxy, Gauntlet Navegador (Firefox, Safari, Internet Explorer)

Tabela 2: Componentes do REST O agente do usurio utiliza um conector do tipo cliente para iniciar uma requisio e, em seguida, se torna o destino nal de uma resposta. O tipo mais comundo de um agente do usurio o navegador Web, que prov acesso a informaes (recursos) e processa as respostas (representaes) de forma que a ser vizualizada pelo usurio de acordo com a necessidade. Um servidor de origem utiliza um conector do tipo servidor e trata das requisies de um cliente. o servidor, tambm, a fonte de todas as representaes dos seus recursos disponveis aos clientes. Cada servidor deve prover seus servios atravs de uma interface genrica para a sua hierarquia de recursos, detalhes de implementaes destes recursos cam escondidos por esta interface. Outra caracterstica chace de um servidor de origem ele ser o destino nal de qualquer requisio feita por um cliente e que visa modicar Os outros dois componentes, gateway e proxy, podem atuam, ao mesmo tempo, como cliente e servidor para a exercer a funcionalidade de encaminhamento de requisies e respostas. Mais especicamente, o proxy um componente intermedirio explicitamente escolhido pelo cliente para exercer encapsulamento de outros servios, deslocamento de dados, aumento de performance ou algum tipo de controle de acesso de segurana. J o gateway transparente ao usurio e utilizado pelo servidor de origem dos recursos, funciona como um proxy reverso, prov os mesmos servios que um proxy porm, a diferena entre os dois que o proxy utilizado (ou no) explicitamente pelo usurio, enquanto que o gateway imposto pelo servidor.

22

4

Web - Uma Aplicao REST

A Web um bom exemplo de aplicao REST existente. Muito do que h nela segue ou pode ser feito de forma a seguir os principios do estilo REST.[3] A Web consiste basicamente de um sistema de localizao de recursos (URI), do protocolo de comunicao HTTP, linguagens de marcao de contedo (HTML, XML, etc) e outras tecnologias da internet, como servidores de domnio (DNS).

4.1

Localizao de Recursos Atravs de URI

Uma URI1 uma cadeia de caracteres compacta utilizada para identicar um nome ou um recurso.[4] Ela contm o mnimo de informao necessria para que se possa acessar um recurso.[5]

Figura 4: Exemplo de URI Como possvel observar na gura 4, uma URI composta de vrias partes, cada uma com um signicado particular. A primeira parte (http://) indica o protocolo de comunicao entre o cliente e o servidor para acessar determinado recurso. Na seqncia aparece o nome do servidor hospedeiro das informaes. Por ltimo, separado do nome do servidor por uma barra (/), vem o nome completo do recurso. Este formato de URI chamado de URI absoluta, pois ela fornece o caminho absoluto para acessar um recurso. O processo de localizao de um recurso iniciado no cliente atravs da resoluo do nome do servidor, isto , a transformao deste nome em um endereo de rede. No caso da Internet o1 Identicador

Uniforme de Recursos (Uniform Resorce Identier)

23

endereo de rede corresponde a um endereo IP. Aps conhecer o endereo de rede do servidor o cliente inicia uma conexo utilizando o protocolo especicado na URI e, em seguida, requisita ao servidor o recurso contido no resto da URI.

(1) ../xpto/meuRecurso (2) /mensagens/primeiraMensagemAlm da forma absoluta, uma URI pode ser expressa de forma relativa. Os exemplos (1) e (2) acima representam URIs nesta forma. possvel observar, atravs desses exemplos, que so suprimidas as informaes de protocolo e nome do hospedeiro. Estas informaes devem ser obtidas com base em um contexto onde foram utilizadas estas URIs relativas e por isso elas no vlidas quando aparecem sozinhas, fora de um contexto.

4.2

HTTP

O protocolo de transferncia de hipertexto, HTTP2 , utilizado na Web como meio de transferncia de recursos atravs da Internet. Caractersticas do HTTP incluem a possibilidade de ausncia de estados entre as conexes, mecanismos de controle para cache de informaes, a possibilidade do uso de diversas camadas de servios, o estilo cliente-servidor e a uniformidade do formato de representao dos dados dos recursos transferidos. Todas estas caractersticas entram em acordo com o estilo arquitetural REST. A primeira verso do protocolo, chamada de 0.9, possua apenas o mecanismo de busca de recursos (GET) e no suportava especicaes de verso de protocolo e cabealhos de informao nas trocas de mensagem. A falta de um mtodo de envio de informaes do cliente para servidor (o mtodo POST) limitava muito suas funcionalidades. Em 1996 surgiu a verso 1.0 do protocolo que ainda hoje utilizada. Esta verso j trazia, alm do mtodo GET tambm trazia mtodos de envio de informaes (POST) e um outro mtodo de busca de recursos chamado HEAD. Este ltimo funcionava de forma idntica ao GET porm s retornava as metainformaes referentes a um recurso e no o recurso por completo. A verso atualmente utilizada a 1.1 que incorpora diversas novas caractersticas. No escopo deste trabalho a mais importante a adio de dois novos mtodos, PUT e DELETE. Os mtodos GET e HEAD so denidos como seguros, o que signica que eles so apenas para a recuperao de recursos e no devem alterar o estado de nenhuma informao presente2 Hipertext

Transfer Protocol

24

no servidor, ou seja, o uso destes mtodos no tem efeitos colaterais no estado dos recursos no servidor. PUT e DELETE so mtodos idempotentes, isto , mltiplas operaes idnticas tem o mesmo efeito colateral que apenas uma. Como os mtodos GET e HEAD so seguros, so inerentemente idempotentes.

4.2.1

Mtodo GET

O mtodo GET signica "recupere qualquer informao que esteja identicada pela URI de requisio".[6] Se a URI se refere a um processo que produz dados, os dados produzidos sero retornados como resposta requisio. Quando acessamos uma pgina atravs de um navegador estamos executando o mtodo GET para a obteno desta pgina e os recursos pertencentes a ela (imagens, outras pginas, etc). Uma resposta pode ser passvel de cache quando isto sinalizado explicitamente pelo servidor atravs de metainformaes embutidas na resposta. Abaixo um exemplo de requisio GET feita ao recurso / para o servidor HTTP em www.google.com. A linha precedida por a requisio feita pelo cliente, enquanto que os dados precedidos de so respostas enviadas pelo servidor.

>> GET / > POST /path/script.cgi HTTP/1.0 From: frog@jmarshall.com User-Agent: HTTPTool/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 32 home=Cosby&favorite+flavor=fliesNo exemplo acima enviado ao servidor uma requisio POST para o recurso /path/script.cgi com os dados home=Cosby&favorite+avor=ies. Todo o resto da requisio so metadados que informam o tipo do contedo da requisio e alguns outros detalhes.

26

Referncias Bibliogrcas[1] BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture in Practice. 2. ed. [S.l.]: Addison-Wesley Professional, 2003. [2] FIELDING, R. Architectural Styles and the Design of Network-based Software Architectures. 100 p. Tese (Doutorado) University of California, 2000. [3] BAKER, M. Whatisrest. Disponvel em: bin/wiki.pl?WhatIsREST>. Acesso em: 02 dez. 2007.