FACULDADE DE TECNOLOGIA DE SO PAULO

WEB SERVICES (SOAP X REST)

SO PAULO
2012

FACULDADE DE TECNOLOGIA DE SO PAULO

WEB SERVICES (SOAP X REST)

Jean Carlos Rosrio Lima

Monografia apresentada Faculdade de Tecnologia de So Paulo
para a obteno do Grau de Tecnlogo em Processamento de Dados
Orientador: Prof. Irineu Aguiar

SO PAULO
2012

RESUMO
Este trabalho tem como objetivo, demonstrar a tecnologia Web Services, sua importncia e
popularidade. Demonstrando assim as tecnologias que so utilizadas dentro do cenrio dos
Web Services, assim como as novas tendncias que surgiram com o amadurecimento dos
sistemas distribudos. Dentre as tecnologias que sero abordadas neste trabalho, temos: XML,
SOAP ,WSDL e UDDI. Por fim, analisaremos a abordagem REST em oposio ao protocolo
SOAP de forma a demonstrar vantagens e desvantagens na utilizao de ambas as
abordagens.

ABSTRACT

This paper aims to demonstrate the Web Services technology, its importance and popularity.
Thus demonstrating the technologies that are used within the scenario of Web services, as
well as new trends that have emerged with the maturation of distributed systems. Among the
technologies that will be addressed in this work, we have: XML, SOAP, WSDL and UDDI.
Finally, we analyze the REST approach as opposed to the SOAP protocol in order to
demonstrate advantages and disadvantages in the use of both approaches.

LISTA DE ABREVIATURAS E SIGLAS

REST
ROA
CORBA
WSDL
W3C
UDDI
RPC
SOAP
XML
URI
XSD

Representational State Transfer

Arquitetura Orientada a Servio
Common Object Request Broker Architecture
Web Services Description Language
World Web Wide Consortium
Universal Description Discovery and Integration
Remote Procedure Call
Simple Object Access Protocol
Extensible Markup Language
Uniform Resource Identifier
XML Schema Definition

SUMRIO
INTRODUO ............................................................................................................................................... 7
I WEB SERVICES ......................................................................................................................................... 8
I.1 ORIGEM ....................................................................................................................................................... 8
I.2 DEFINIO ................................................................................................................................................... 8
I.3 PAPIS ....................................................................................................................................................... 11
II RPC........................................................................................................................................................... 13
II.1
II.2
II.3
II.4

O QUE RPC ? .......................................................................................................................................... 13

COMO FUNCIONA ? .................................................................................................................................... 13
INTERFACE RPC........................................................................................................................................ 14
DESENVOLVENDO RPC ............................................................................................................................. 16

III SOAP ....................................................................................................................................................... 17

III.1
III.2
III.3
III.5
III.6
III.7
III.7
III.8

CONCEITO ............................................................................................................................................... 17
CARACTERSTICAS ................................................................................................................................... 18
FORMATO DE MENSAGEM ........................................................................................................................ 18
ENVELOPE SOAP ..................................................................................................................................... 19
CABEALHO SOAP .................................................................................................................................. 20
ATRIBUTOS SOAP .................................................................................................................................. 21
CORPO SOAP .......................................................................................................................................... 22
TRATAMENTO DE EXCEES SOAP ......................................................................................................... 24

IV REST ....................................................................................................................................................... 25
IV.1
IV.2
IV.3
IV.4

CLIENTE/ SERVIDOR................................................................................................................................. 26
CAMADAS ............................................................................................................................................... 27
CACHE .................................................................................................................................................... 28
SEM ESTADO ........................................................................................................................................... 28

V ARQUITETURA ORIENTADA A RECURSOS ..................................................................................... 29

V.1 CONCEITO ................................................................................................................................................ 29
V.2 RECURSOS ................................................................................................................................................ 30
V.3 URIS ........................................................................................................................................................ 30
V.4 URIS DEVEM SER DESCRITIVAS .................................................................................................................. 31
V.5 URIS X RECURSOS ................................................................................................................................... 32
V.6 ENDEREAMENTO ..................................................................................................................................... 32
V.7 FALTA DE ESTADO ..................................................................................................................................... 33
V.8 REPRESENTAES ..................................................................................................................................... 35
V.9 MLTIPLAS REPRESENTAES .................................................................................................................. 36
V.10 ENCADEAMENTO ..................................................................................................................................... 37
V.11 A INTERFACE UNIFORM ........................................................................................................................... 38
V.12 SEGURANA E IDEMPOTNCIA ................................................................................................................. 38
VI REST X SOAP......................................................................................................................................... 39
VI.1 VANTAGENS DO SOAP ............................................................................................................................ 39
VI.2 DESVANTAGENS DO SOAP ....................................................................................................................... 39
VII CONCLUSO........................................................................................................................................ 40
REFERNCIAS BIBLIOGRFICAS .......................................................................................................... 41

INTRODUO
A utilizao da tecnologia de Web Services vem se popularizando nos ltimos anos. Com o
aumento da confiana do consumidor para realizar transaes pela INTERNET, as empresas
esto utilizando cada vez mais essa tecnologia.
Os Web Services so bastante utilizados em aplicaes de comrcio eletrnico. Um bom
exemplo a integrao do comrcio eletrnico com o servio dos correios, o qual possibilita
que o usurio informe o nmero do CEP e o servio dos correios se encarrega de retornar o
respectivo endereo para o CEP informado.
O XML a tecnologia responsvel por essa interoperabilidade, conectando programas e
aplicaes desenvolvidas em diferentes linguagens ou plataformas. (EXTENSIBLE, 2011)
O objetivo deste trabalho demonstrar a integrao da tecnologia de Web Services em
sistemas heterogneos nas suas diferentes abordagens: SOAP E REST.

I Web Services
I.1 Origem
Com a evoluo das redes de computadores surgiram as aplicaes distribudas.
Inicialmente todo o processamento era centralizado em apenas um servidor. Com o
surgimento dos middlewares o processamento comeou a ser distribudo entre vrios
servidores. Com o avano da internet e dos protocolos de comunicao baseados em XML,
surgiram os Web Services com a misso de integrar sistemas heterogneos. (GOMES, 2010)

I.2 Definio
Segundo definio do W3C, os Web Services so aplicaes autocontidas, que possuem
interface baseadas em XML e que descrevem uma coleo de operaes acessveis atravs da
rede, independente da tecnologia usada na implementao do servio. (WEB, 2011)
O XML o formato de mensagem adotado pelo W3C para troca de informaes entre
aplicaes distribudas atravs do protocolo HTTP. O SOAP por ser uma tecnologia sem
caractersticas proprietrias tornou-se uma alternativa aos protocolos tradicionais, tais como:
CORBA e DCOM. (GOMES, 2010)
Os Webs Services devem ser definidos de forma consistente para que possam ser
descobertos e interfaceados com outros servios e aplicaes. A WSDL uma especificao
W3C que fornece a linguagem mais avanada para a descrio de definies de Web Services.
A figura 1 abaixo mostra a definio de um documento WSDL.

A camada de integrao introduzida pela estrutura de Web Services estabelece um padro,

universalmente reconhecido e com interface suportada. Tal como mostrado na figura 1, a
WSDL permite a comunicao entre essas camadas ao fornecer descries padronizadas.
Simplificadamente, pode se dizer que o arquivo WSDL um documento XML que descreve
um conjunto de mensagens SOAP e a forma como essas mensagens so trocadas.
Para enxergar o valor do WSDL, imagine que voc quer invocar um mtodo SOAP que
fornecido por um dos seus parceiros de negcio. Voc pode pedir alguns exemplos de
mensagens SOAP e escrever sua aplicao para produzir e consumir mensagens que se
parecem com os exemplos fornecidos, mas isso pode gerar muitos erros. Por exemplo, voc
pode assumir que um campo um inteiro, quando de fato o mesmo uma string. O WSDL
especifica o que a mensagem de requisio deve conter e como vai ser a resposta, em uma
notao no ambgua.
A notao que o arquivo WSDL usa para descrever o formato das mensagens baseada no
padro XML, o que significa que uma linguagem de programao neutra, baseada em
padres. O que a torna adequada para descrever as interfaces dos Web Services, que so
acessveis por uma grande variedade de plataformas e linguagens de programao. Alm de
descrever o contedo das mensagens, o WSDL define onde o servio est disponvel e quais
protocolos de comunicao so usados para conversar com o servio. Isso significa que o
arquivo WSDL define tudo que necessrio para escrever um programa que utilize o XML
Web Service.

10
UDDI o responsvel pela publicao e descoberta dinmica dos servios Web Services.
Para fazer uma chamada a um Web Service necessrio localiz-lo e em seguida descobrir
sua interface e a semntica da sua chamada e escrever e configurar o software local que
realizar a chamada ao Web Service. (UNIVERSAL, 2011)
UDDI so as pginas amarelas dos Web Services. Assim como nas pginas amarelas
tradicionais, voc pode procurar por uma companhia que oferea os servios que voc precisa
ler sobre o servio oferecido e contatar algum para obter mais informaes sobre o servio
disponibilizado. Voc pode naturalmente oferecer um servio sem registr-lo na UDDI, assim
como voc pode abrir um negcio no poro de sua casa e contar com a propaganda boca a
boca, mas se voc quiser alcanar um mercado significativo, voc precisar do UDDI, assim
seus clientes podero encontr-lo.
Um diretrio UDDI um arquivo XML que descreve o negcio e os servios. O mesmo
possui trs partes:
Pginas brancas: Descrevem a empresa (Nome, Endereo, Contatos).
Pginas amarelas: Incluem as categorias, baseadas em taxonomias padres.
Pginas verdes: Descreve a interface para o servio, em nvel de detalhe suficiente
para escrever uma aplicao que use Web Service.

O diretrio UDDI tambm inclui vrias maneiras de procurar os servios. Por exemplo,
pode se procurar fornecedores de um determinado servio em uma regio especfica.

11

I.3 Papis
H trs papis importantes dentro da arquitetura de Web Services: Provedor de Servios,
Consumidor de servios e o Registro dos servios. A interao destes papis envolve as
operaes de publicar, pesquisar e fazer a ligao dos servios. Abaixo definida a funo
para cada um destes papis:
Provedor de servios: o responsvel pela implementao e disponibilizao dos
Web Services na INTERNET. Para que algum possa utiliz-lo, preciso descrever o
servio em um formato padro, compreensvel para qualquer um que precise usar
esse servio e tambm publicar as caractersticas sobre o servio em um registro
central disponvel.
Consumidor de servios: o usurio de um servio disponvel na INTERNET que foi
implementado por um provedor de servio.
Registro do servio: Refere-se localizao do servio. Ele contm as informaes
tcnica dos servios e os detalhes da empresa.
A figura 2 ilustra a interao entre os elementos da arquitetura Web Services.

12

O provedor o responsvel pela publicao da descrio de um determinado servio. O

Consumidor por sua vez, faz a utilizao de tal descrio para encontrar o servio
disponibilizado pelo provedor.
As comunicaes entre as aplicaes de Web Services fazem uso de quatro elementos que
fazem o encapsulamento da requisio e resposta entre um servidor e um cliente. Estes
elementos so:
XML
SOAP
WSDL
UDDI
A figura abaixo ilustra como esses elementos se relacionam.

13

II RPC

II.1 O que RPC ?

O RPC uma tcnica utilizada no desenvolvimento de aplicaes distribudas que segue o
modelo cliente-servidor. (REMOTE, 2011)
O mesmo tem por finalidade permitir que um procedimento local possa ser estendido, ou
seja, que o procedimento chamado possa existir em um espao de endereamento remoto.
O RPC trabalha com o modelo cliente-servidor. Ambos podem estar no mesmo computador
ou em computadores diferentes conectados atravs uma rede.
Com o uso de RPC, um programador de uma aplicao distribuda pode evitar ter que tratar
de detalhes de baixo nvel impostos pela interface com a rede.
Primeiras implementaes comerciais:
ONC RPC (tambm conhecida como SUNRPC
Disponvel na maioria dos sistemas UNIX
Cdigo aberto disponvel desde 1988

II.2 Como funciona ?

Um procedimento remoto identificado de forma unvoca pela trinca:
Nmero do Programa: Identifica um grupo de procedimentos remotos relacionados.
Sendo que cada programa possui um nmero de procedimento diferente.
Nmero da Verso: Um programa pode consistir de uma ou mais verses.

14

Nmero do Procedimento: Identifica o programa em uso.

Quando o servidor inicia, ele registra-se atravs do servio portmapper. Ele tambm
registra os nmeros de programa e de verso dos procedimentos que disponibiliza. Antes que
o cliente possa fazer uma chamada RPC, ele consulta o portmapper do servidor para
identificar a porta em que o servidor est ativo para realizar a comunicao. Por fim, o cliente
e servidor estabelecem um canal de comunicao.
Aps o canal ter sido estabelecido. A chamada RPC funciona da seguinte forma:
1. O cliente faz uma chamada que envia uma requisio ao servidor e aguarda a
resposta.
2. O cliente bloqueado at o recebimento de uma resposta ou se o tempo de espera
(timeout) se esgotar.
3. Quando a requisio enviada ao servidor, o mesmo chama um procedimento que
fornece o servio solicitado e envia a resposta de volta para o cliente.
4. Aps o recebimento da resposta pelo cliente, este continua a sua execuo.

II.3 Interface RPC

A interface de programao RPC dividida em nveis. Esses nveis oferecem diferentes
possibilidades de controle sobre os detalhes envolvidos na comunicao entre o cliente e o
servidor. Em outras palavras, quanto maior for o controle desejado, maior ser a quantidade
de cdigo necessria. Existem cinco nveis:
Simples: Realiza chamadas de procedimento e registra o servidor
Alto: Alm de realizar chamadas. possvel configurar cliente e servidor.
Intermedirio: Especifica o tipo de transporte.

15

Especialista: Especifica detalhes do transporte.

Baixo: Tem total controle sobre o transporte.
O nvel simples composto basicamente por duas funes: callrpc e registerrpc. A funo
callrpc responsvel por fazer a chamada do procedimento remoto no lado do cliente e
recebe os seguintes parmetros:
Nome do Servidor
Nmero do Programa
Nmero do Procedimento
Filtro XDR: Responsvel por codificar o argumento; ponteiro para o argumento. E
decodificar o retorno e endereo para o retorno.
J o registerrpc responsvel por realizar o registro do procedimento no lado do servidor,
o mesmo recebe os seguintes parmetros:
Nmero do Programa
Nmero da Verso
Nmero do Procedimento
Nome do Procedimento
Filtro XDR: Responsvel por codificar o argumento e decodificar o retorno.
Essas funes escondem todos os detalhes de rede, impedindo o controle sobre diversos
detalhes da comunicao. Como por exemplo, o tipo de transporte utilizado.

16

II.4 Desenvolvendo RPC

Na maioria dos casos, no necessrio conhecer alm do nvel simples da interface RPC,
para que se construa um servio do tipo RPC. Atravs de programas auxiliares possvel
gerar a interface de forma automtica, sem a necessidade de codificar. O programador precisa
apenas implementar o cdigo da aplicao.
Para desenvolver uma aplicao RPC os seguintes passos so necessrios:
1. Especificar o protocolo para a comunicao cliente/servidor:
A maneira mais fcil para definir o protocolo criar um arquivo usando uma
linguagem especial.
Nesse arquivo deve-se definir o nome dos procedimentos, os parmetros dos
procedimentos e os tipos de retorno.
O compilador do protocolo l esse arquivo e automaticamente gera grande parte do
cdigo necessrio para a programao da aplicao RPC
2. Programar o cliente e o servidor.
3. Compilar os programas.
4. Disparar os servios necessrios.

Para que uma aplicao RPC funcione necessrio que o servio portmapper
esteja em execuo.

5. Executar os programas.

17

III SOAP

III.1 Conceito
O SOAP um protocolo projetado para invocar aplicaes remotas atravs de RPC ou
trocas de mensagens, em um ambiente independente de plataforma e linguagem de
programao. (SIMPLE, 2011)
fcil de implementar, testar e usar o protocolo SOAP. Ele um padro da indstria e foi
adotado pelo W3C. A mensagem transportada atravs do protocolo HTTP por meio de
pacotes virtualmente idnticos .Os protocolos de autenticao e encriptao so os mesmos.
O SOAP beneficia-se da infraestrutura criada para o HTTP para atravessar firewalls e
roteadores, o que facilita a comunicao entre os Web Services envolvidos.
Inicialmente o SOAP foi construdo como um veculo genrico para troca de mensagens
entre computadores atravs da INTERNET. O formato de mensagem refere-se ao estilo
utilizado entre as aplicaes Web Services. O estilo de comunicao a ser utilizado entre um
cliente (Web Services) e um servio vai depender da forma que o servio foi implementado.
Os Web Services oferecem dois tipos de modelos:
RPC
Document.

O RPC permite modelar chamadas de mtodos com parmetros e receber valores de retorno.
Uma mensagem SOAP leva em seu corpo (elemento Body), o nome do mtodo a ser
executado e os parmetros de entrada da chamada. Na mensagem RPC de resposta, um valor
de retorno ou uma falha do mtodo invocado retornado.
No Document, o corpo da mensagem SOAP contm um fragmento de documento XML que
enviado ao servio em vez de um conjunto de valores de parmetros.

18

O modelo utilizado para a comunicao SOAP nos Web Services, influi diretamente em seu
desempenho e em sua confiabilidade. Web Services implementados no estilo RPC necessita
somente da elaborao da interface de suas operaes, enquanto que no estilo Document exige
mais esforo de implementao, pois requer a criao de um XML Schema, o qual necessita
da descrio dos elementos que correspondem s operaes do servio e os respectivos tipos
de dados utilizados nos parmetros das operaes.

III.2 Caractersticas
Definido pelo consorcio W3C.
Protocolo baseado em XML para troca de informaes em ambientes distribudos
Padro de utilizao para Web Services.
Normalmente utiliza HTTP como protocolo de transporte.

III.3 Formato de Mensagem

Uma mensagem SOAP consiste basicamente dos seguintes elementos:

19

Envelope: o elemento principal do XML que representa a mensagem.

Header: um mecanismo genrico que permite a adio de caractersticas
mensagem SOAP de forma descentralizada, sem acordo anterior entre as partes
comunicantes.
Body: Este elemento contm a informao a ser transportada.

III.4 Especificao do Protocolo

A especificao do protocolo SOAP est dividida em quatro partes:

SOAP Envelope: Define o que h na mensagem e como process-la. a nica parte
do protocolo que obrigatria.
SOAP Encoding Rules: Define um mecanismo de serializao que pode ser usado
para troca de instncias de tipos definidos pela aplicao.
SOAP RPC Style: Define uma conveno que pode ser usada para representar as
chamadas e respostas remotas aos procedimentos.
LINK SOAP HTTP: Define um protocolo que liga o SOAP e o HTTP. Ele descreve
como as mensagens SOAP so transmitidas via HTTP.

III.5 Envelope SOAP

Este elemento parte obrigatria de uma mensagem SOAP. Ele funciona como um
recipiente que comporta os demais elementos da mensagem, tais como: O cabealho
(Header), o corpo (Body) e os respectivos namespaces de cada um. Da mesma forma que o
correio entrega uma carta baseando-se pelo nome e endereo do destinatrio, o elemento

20

envelope precisa destas informaes do protocolo de transporte que est ligado a ele, com o
propsito de garantir o envio da mensagem para o local correto. O Envelope pode possuir um
cabealho que se chama SOAP ACTION que indica o endereo de entrega da mensagem. Um
dos principais motivos para inserir o cabealho para que os administradores de sistemas
possam configurar seus firewalls para filtrar as mensagens baseadas nas informaes dos
cabealhos.
A figura 5 tem um exemplo de formatao do Envelope SOAP

III.6 Cabealho SOAP

Este elemento opcional em uma mensagem SOAP. Ele contm informaes adicionais,
como por exemplo, se a mensagem deve ser processada por um determinado n intermedirio.
importante lembrar que ao trafegar pela rede, a mensagem passa por diversos pontos
intermedirios at alcanar o seu destino final. Quando utilizado, o cabealho deve ser o
primeiro elemento do Envelope.

21

III.7 Atributos SOAP

Existem trs atributos no SOAP que podem ser utilizados na composio de uma
mensagem:
Atributo encodingStyle: indica as regras deserializao usadas nas mensagens
SOAP. Podendo aparecer em qualquer elemento, o seu escopo todo o contedo do
elemento, assim como os elementos filhos. O valor deste atributo uma lista de uma
ou mais URIs , os quais identificam as regras de serializao ou deserializao,
indicadas na ordem da mais especfica para a mais abrangente. Exemplos de valores
para o atributo encodingStyle.

A terceira linha, corresponde a um valor vazio, indicando que no h requisio de

encodingStyle para o elemento contido. Pode ser utilizado para decodificar uma requisio
feita a um elemento pai.
Atributo actor: algumas aplicaes SOAP so chamadas intermedirias, pois tem a
possibilidade de encaminhar e receber a mensagem SOAP. Uma mensagem SOAP
pode sair de um remetente para um destinatrio e, potencialmente, passar por vrias
aplicaes SOAP intermedirias. Nem todas as partes de uma mensagem SOAP
interessam a um destinatrio, assim como podem interessar a um ou mais
intermedirios no caminho da mensagem. Quando uma aplicao SOAP A recebe
um elemento de cabealho, ela dita receptora e encara o cabealho como um
contrato entre ela e quem repassou a mensagem. Assim ao enviar a mensagem para

22

outra aplicao B, a aplicao A deve incluir um cabealho similar ao atual, mas

no caso, o contrato deve ser entre A e B. O atributo actor pode ser utilizado como
um indicador de receptor de um elemento de cabealho. Funciona como um meio de
hops representado pelo campo Connection do cabealho do HTTP. O valor uma
URI, que se for vazio, designa o receptor como o destinatrio.

Atributo mustUnderstand : Este atributo pode ser utilizado para indicar se uma
entrada do cabealho obrigatria ou opcional para o receptor processar.

III.7 Corpo SOAP

Este elemento obrigatrio na mensagem SOAP, o corpo (Body) armazena os dados de

uma chamada de um mtodo em particular, como o nome do mtodo e parmetros de entrada
e sada e o respectivo resultado produzido pelo mtodo. Ele est presente logo aps o
cabealho (Header) da mensagem, se este existir. Caso no informado, dever aparecer
imediatamente aps a tag de abertura do envelope.
O contedo do corpo da mensagem SOAP depende se ela uma requisio ou uma resposta.
Se for uma requisio, ele contm informaes sobre a chamada do mtodo, se for uma
resposta ir conter os dados do resultado da chamada ao mtodo.
Nas figuras abaixo. Temos uma demonstrao de uma requisio, utilizando o protocolo
SOAP. Na figura 8 informado o valor do parmetro do mtodo GETPRICE. J na figura 9
temos o retorno da requisio, ou seja, retornado o preo do item informado.

23

A especificao SOAP define os tipos de dados baseados no XSD. Esta especificao define
os tipos primitivos de dados, assim como estruturas mais complexas. Uma grande vantagem
do uso do protocolo SOAP que ele aceita qualquer tipo de dado que possa ser representado
por um XSD Schema. Na tabela 1 temos os tipos aceitos pelo XSD.

24

III.8 Tratamento de Excees SOAP

Os mtodos acessados atravs do protocolo SOAP no esto livres de erros, por isso
necessitam de um dispositivo para identific-los. Estes erros ou excees que ocorrem nos
Web Services devem ser retornados ao consumidor de alguma maneira, assim o Mtodo de
Exceo (Fault) executa esse trabalho. As excees SOAP podem acontecer em vrios
estgios durante o processamento de uma requisio a um servio.
Se a falha acontecer durante o transporte da mensagem, a camada do HTTP ser
responsvel pela notificao do erro. Se o erro ocorrer na prpria execuo do protocolo
SOAP, o mesmo tratar a exceo gerada.

25

IV REST

Foi idealizado por Roy Fielding no ano de 2000, na sua dissertao de doutorado, na qual
buscou as melhores prticas nos estilos de arquiteturas existentes para compor um novo estilo
que as reunissem em apenas um estilo, o qual ficou conhecido como REST.
REST um estilo de arquitetura direcionado para sistemas de hipermdia distribudos.
Basicamente esse estilo composto por dois papis: Cliente e Servidor. Conforme figura
abaixo.

O REST basicamente o resultado das melhores prticas dos seguintes estilos:

26

Cliente / Servidor.
Sistema em Camadas
Cache
Sem estado

IV.1 Cliente/ Servidor

Neste modelo so definidos dois papis: Cliente e Servidor. Basicamente o servidor

disponibiliza um conjunto de servios e o cliente faz uso desses servios.
O cliente envia requisies para o servidor, este por sua vez ao receb-las toma a deciso de
aceit-las ou no.

Clientes e Servidores comunicam-se atravs de uma rede de computador com hardwares

separados, porm o cliente e o servidor podem residir no mesmo sistema. A mquina
servidora um host que est executando um ou mais programas que compartilham os seus
recursos com os clientes. O cliente por sua vez no compartilha recursos, ele solicita servios
ao servidor.

27

Funes como a troca de e-mail, acesso INTERNET e acesso ao banco de dados, so

construdos com base no estilo cliente-servidor. Por exemplo, um navegador da web um
programa cliente em execuo no computador do usurio que pode acessar informaes
armazenadas em um servidor web na INTERNET.

IV.2 Camadas

No sistema em camadas, o mesmo divido em camadas, onde cada camada conhece apenas
a interface da camada superior. As camadas intermedirias podem ser utilizadas para melhorar
a escalabilidade do sistema, permitindo o balanceamento de carga de servios, atravs de
mltiplas redes. (FIELDING,2000)

A desvantagem do sistema em camadas que eles adicionam sobrecarga ao tratamento de

dados. Essa perda de desempenho pode ser compensada se a rede for configurada para
suportar cache.

28

IV.3 Cache
A arquitetura cache evita desperdcio de banda, pois evita que dados que j tenham sido
enviados anteriormente ao cliente sejam reenviados. Na primeira vez que uma pgina
solicitada pelo cliente a mesma armazenada num Proxy HTTP.( (FIELDING,2000)
A vantagem de se utilizar cache a eliminao parcial ou total de algumas interaes entre
cliente e servidor, o que melhora a eficincia ( menos trafego de rede) , escalabilidade (
menos processamento) e performance , j que o servidor fica menos carregado.

IV.4 Sem Estado

Nesta arquitetura o servidor no armazena nenhuma informao de contexto. Toda
informao necessria para atender a uma requisio deve estar contida nela mesma. Isto
torna o servidor mais simples, pois ele no precisa levar em considerao o contexto atual
para tomar decises, toda informao necessria ser enviada a ele a cada requisio.
(FIELDING,2000)

29

V ARQUITETURA ORIENTADA A RECURSOS

V.1 Conceito

A arquitetura orientada a recursos (ROA) permite transformar um problema em um servio

web REST. Foi desenvolvida por Sam Ruby e Leonard Richardson.
ROA composta por quatro conceitos:

Recursos
URIs
Representaes
Links entre elas
e quatro propriedades:
Endereamento
Falta de Estado
Encadeamento
Interface Uniforme

30

V.2 Recursos
Um recurso algo que pode ser armazenado em um computador e representado por uma
sequncia de bits, por exemplo, um documento, uma imagem, um registro de uma tabela ou o
resultado da execuo de um algoritmo.( RICHARDSON,2007)
Exemplos de recursos disponveis na web:
Informaes sobre REST
Um mapa rodovirio
ltima verso de um determinado software
A relao entre dois conhecidos: Joo e Maria
Um diretrio de recursos sobre Web Services
Nmero de Vendas para o Q2-2012

V.3 URIs

O que torna um recurso um recurso? Ele tem que ter pelo menos uma URI. A URI
representa o nome e o endereo de um recurso. Se uma parte das informaes no tiver uma
URI, no ser um recurso e , portanto no estar na web. .( RICHARDSON,2007)
A URI a tecnologia fundamental da web. Existiam sistemas de hipertexto antes do HTTP,
mas eles no se comunicavam. A URI interconectou todos estes protocolos da INTERNET
em uma web, da mesma forma como o TCP/IP interconectou redes como Usenet, Bitnet e
CompuServe em uma nica INTERNET.
Hoje navegamos na web, fazemos download de arquivos na web( no em sites FTP),
pesquisamos publicaes na web ( no no WAIS) e conversamos na web ( no nos

31

newsgroups Usenet). Os sistemas de controle de verso, por exemplo, o Subversion e o Arch,

funcionam na web.
A web acaba com os outros protocolos, pois tem algo que a maioria dos protocolos no tem:
um modo simples de identificar todo tem disponvel na web. Todo recurso na web tem pelo
menos uma URI. Voc pode obter uma URI a partir de qualquer browser e essa mesma URI
pode ser enviada para um amigo, que o mesmo poder acessar as mesmas informaes. Pode
parecer simples essa tarefa em nossos dias, mas esta interao seria impossvel antes da
existncia das URIs.

V.4 URIs devem ser descritivas

As URI e seus recursos devem possuir uma correspondncia clara. Abaixo esto algumas
URIs ideais para os recursos listados acima:
http://www.exemplo.com/wiki/rest;
http://www.exemplo.com/mapa/rodoviario/nome_do_mapa;
http://www.exemplo.com/software/versao/1.0.3.tar.gz;
http://www.exemplo.com/relacionamento/joao;maria;
http:/www.exemplo.com/search/webservices;

http://www.exemplo.com/vendas/2012/02;

As URIS devem ser intuitivas para o usurio, de modo que os mesmos possam l-las e
interpret-las com facilidade. (UNIFORM, 2011)

32

V.5 URIs x Recursos

Dois recursos podem ser iguais? Duas URIs podem designar o mesmo recurso? Uma nica
URI pode designar dois recursos?
Por definio dois recursos no podem ser iguais. Se fossem, teramos apenas um recurso.
Mas em algum momento dois recursos podem apontar para os mesmos dados. Se a verso
atual de um determinado software for 1.03, ento as URIs abaixo podero representar os
mesmos dados por um determinado perodo de tempo. Porm so dois conceitos distintos, um
refere-se a uma determinada verso e o outro refere-se verso mais recente. At que surja
uma nova verso, ambas as URIs estaro apontando para os mesmos dados.

http://www.exemplo.com/software/versao/ultimaversao.tar.gz
http://www.exemplo.com/software/versao/1.03.tar.gz;
Um recurso pode ter uma ou vrias URIs. Se um recurso tiver diversas URIs , ser mais
fcil para os clientes referirem-se a ele. Em contrapartida alguns clientes podem utilizar uma
URI ou outra perdendo-se assim o controle automtico de qual URI est sendo utilizada.
Toda URI est associada a apenas um recurso. Porm, quando voc recupera uma URI, o
servidor pode enviar-lhe informaes sobre diversos recursos: o solicitado e o relacionado a
outros. Ao realizar uma pesquisa em um site de busca, o servidor disponibiliza alm do
recurso que estamos pesquisando, todas as informaes que esto associadas a ele.

V.6 Endereamento
O recurso enderevel quando um usurio pode acessar os seus dados atravs de uma
determinada URI.
O endereamento o aspecto mais importante de qualquer site ou aplicao web. Seno
fossem pelo endereamento os sites mais conhecidos, aqueles que utilizamos diariamente, no

33

seriam facilmente encontrados. Por exemplo, se quisssemos encontrar informaes sobre um

determinado assunto, bastaramos digitar no browser a URI abaixo:
http://www.google.com.br/search?q=assuntodesejado;
Se o HTTP no fosse enderevel ou se o mecanismo de pesquisa do google no fosse uma
aplicao enderevel, no seriamos capazes de utilizar a URI acima. Teramos que realizar
uma solicitao ao site do google e em seguida informar o objeto da pesquisa.
O endereamento propicia a utilizao de cache de requisies, ou seja, sempre que duas
requisies forem realizadas para o mesmo recurso, em vez de buscar essas informaes
diretamente no servidor, pode-se utilizar um resultado j salvo da requisio anterior num
proxy HTTP da rede local, assim evita o desperdcio de banda . Isto possvel graas ao
endereamento que permite saber quais recursos j foram solicitados.

V.7 Falta de estado

Isso significa que toda solicitao HTTP ocorre em um isolamento completo. Quando o
cliente faz uma solicitao HTTP, ele inclui as informaes necessrias para que o servidor
possa responder a requisio. ( RICHARDSON,2007)
O servidor nunca guarda as informaes das solicitaes anteriores. Se elas fossem
importantes, o cliente no teria que as enviar novamente.
O endereamento diz que toda parte interessante da informao deve ser exibida como um
recurso em sua prpria URI. A falta de estado diz que os possveis estados do servidor
tambm so recursos e devem ser dados em sua prpria URI.
Ao utilizar uma compra pela web, muitas vezes nos deparamos em situaes onde o boto
voltar do navegador no funciona da forma que esperamos. Isso acontece em decorrncia do
site violar o princpio da falta de estado. Tal site espera que voc faa solicitaes em uma
ordem: A , B, C. Ento ele fica confuso quando voc faz a solicitao de B uma segunda vez,
ao invs de ir para a solicitao C.

34

Um mecanismo de pesquisa um servio web com um nmero infinito de possveis estados.

Cada estado tem sua prpria URI. Voc pode solicitar ao servio um diretrio de recursos
sobre REST: http://www.google.com/search?q=REST. Pode solicitar um diretrio de recursos
sobre SOAP: http://www.google.com/search?q=SOAP.
Quando voc solicita um diretrio de recursos sobre REST ou SOAP, apenas parte do
diretrio ser recuperada em uma nica pgina contendo uma lista dos 10 ou mais itens que o
mecanismo de busca considera como os melhores resultados para a pesquisa. Para obter mais
informaes sobre o diretrio, voc deve realizar uma nova solicitao HTTP. A segunda
pgina e as subsequentes so estados distintos da aplicao e possuem suas prprias URIs.
Para recuperar uma segunda pgina sobre SOAP, teramos que utilizar a URI:
http://www.google.com/search?q=SOAP&start=10.
Em uma aplicao sem estado o cliente faz uma solicitao e termina onde comeou. Cada
solicitao totalmente desconectada das outras. O cliente pode fazer solicitaes para esses
recursos vrias vezes em qualquer ordem. Pode solicitar uma pgina2 com informaes sobre
SOAP antes de uma pgina1 com informaes sobre REST e o servidor no se importar.
A figura 15 demonstra um mecanismo de pesquisa sem estado.

Em uma aplicao com estado, o cliente deve seguir uma ordem. Para chegar pgina 2, ele
necessariamente deve passar pela pgina 1.

35

Uma das vantagens da aplicao sem estado que voc capaz de recuperar um diretrio
sobre REST at uma determinada pgina, por exemplo, a pgina 10 do diretrio e voltar
outras vezes na ltima pgina, objeto de sua pesquisa sem ter que passar pelas pginas
anteriores, conforme URI:
http://www.google.com/search?q=rest&start=10

V.8 Representaes

Quando o servidor web envia uma informao de um recurso, esta informao o resultado
de uma srie de bytes em uma linguagem especfica, ou seja, no possvel enviar um recurso
pela web, o que transportado uma representao do recurso. ( RICHARDSON,2007)
Uma representao composta de alguns dados sobre o estado atual de um determinado
recurso. Um recurso apenas um conceito abstrato de algo real, j a representao so os
itens de dados que informam algo sobre o recurso. O nmero de vendas do ltimo semestre de
uma empresa poderia ser representado numericamente ou em um grfico. Ambas as
representaes informam algo sobre o mesmo recurso.
As livrarias online costumam fornecer duas representaes para seus clientes de um mesmo
livro:

36

Uma contendo apenas metadados, como uma imagem e as crticas do livro, usadas
para fazer propaganda do mesmo.
Uma cpia eletrnica dos dados do livro, disponibilizada para download mediante
pagamento.

V.9 Mltiplas Representaes

Se um recurso pode ter uma ou mais representaes, como o servidor pode identificar qual
representao do recurso, o cliente est solicitando?
Uma soluo simples adotada pela ROA seria a utilizao de uma URI distinta para cada
representao de um recurso. Por exemplo, uma notcia publicada no idioma ingls e espanhol
poderia possuir as seguintes URIs:
http://www.exemplo.com/versao/1.04.em
http://www.exemplo.com/versao/1.04.es
A desvantagem dessa prtica que voc exibiria vrias URIs para o mesmo recurso, dando
a impresso que as vrias URIs esto falando de coisas distintas. Para amenizar esse problema
poderia ser criado uma URI ideal, independente da lngua, conforme abaixo:
http://www.exemplo.com/versao/1.04
Esse modo alternativo chamado de negociao de contedo, onde apenas a URI ideal
exibida. Quando um cliente faz uma solicitao para esta URI, fornece cabealhos

de

solicitao HTTP especiais que indicam qual tipo de representao o cliente deseja acessar.
Isso possvel, pois os navegadores web tem uma definio de preferncia de lngua, onde
pode se optar pelo idioma que a representao deve ser exibida.
O mecanismo de pesquisa Google uma boa opo para obter o resultado de uma pesquisa
em praticamente todos os idiomas. Para isso basta apenas alterar a varivel de definio h1na

37

URI (por exemplo, h1=tr para a lngua turca). O mecanismo de pesquisa suporta a negociao
do contedo de um recurso que possui vrias representaes.

V.10 Encadeamento
Quando realizamos uma pesquisa num site de busca, o servidor disponibiliza uma srie de
representaes para o assunto pesquisado. Algumas representaes possuem, alm dos dados,
links com outros recursos. Essas representaes so conhecidas por hipermdia.
Peguemos novamente a URI:
http://www.google.com/search?q=rest
Alm do diretrio de documentos do Google sobre REST, a pgina recupera um conjunto de
links internos com outras pginas do diretrio. A figura abaixo demonstra um encadeamento
resultante da pesquisa.

38

Na figura temos dados e ligaes. Os dados dizem que em algum lugar na web foi
encontrado um diretrio e links internos que fornecem acesso para outros recursos que
informam algo sobre o assunto pesquisado: REST.

V.11 A Interface Uniform

A Interface Uniform define as operaes possveis para um recurso. O HTTP fornece as

seguintes operaes: (HYPERTEXT, 2011)
GET: Recupera uma representao de um recurso.
PUT: Cria ou atualiza um recurso.
DELETE: Apaga um recurso existente.
POST: Cria um recurso subordinado.
HEAD: Recupera metadados de uma representao.
OPTIONS: Verifica quais operaes um determinado recurso suporta.

V.12 Segurana e Idempotncia

Os mtodos do HTTP podem ser classificados quanto a sua segurana e idempotncia Uma
solicitao considerada segura, quando o mtodo utilizado no altera o estado do recurso.
Quando uma mesma solicitao ao ser executada vrias vezes no altera o estado do recurso
a denominamos idempotente.Todo mtodo seguro tambm idempotente. (RICHARDSON,
2007)
Os mtodos GET, HEAD e OPTIONS so seguros e idempotentes, pois no alteram o estado
do recurso.
PUT e Delete no so seguros, mas so idempotentes. O mtodo POST o nico mtodo
que no seguro nem idempotente.

39

VI REST X SOAP

Mencionarei abaixo as vantagens e desvantagens do SOAP em relao ao REST.

VI.1 Vantagens do SOAP

Independncia de transporte: Os cabealhos esto dentro da mensagem, ou seja, eles
so independentes de protocolo para transportar a mensagem. O envelope SOAP pode
ser transportado por qualquer protocolo: HTTP, SMTP, TCP, etc.
Os conceitos sobre segurana so melhores especificados e difundidos nos protocolos
baseados em SOAP do que no protocolo HTTP, utilizado pelo estilo REST.
Os conceitos sobre transao so melhores especificados para o protocolo SOAP.

VI.2 Desvantagens do SOAP

No utilizam todo o poder do HTTP, limitando-se ao mtodo POST para realizar
mltiplas operaes.
muito trabalhoso criar uma interface WSDL manualmente, apesar de terem
ferramentas para ger-las automaticamente, as mesmas tendem ser frgeis.
Todo servio est sob a mesma URI, logo no h encadeamento entre os recursos.
Para resolver esse problema necessrio criar uma WADL, o qual descreve como um
recurso se liga a outro.
Assim como trabalhoso criar uma WSDL, acontece o mesmo quando refere-se
criao do UDDI, talvez seja esse um dos motivos pelo quais ele no se popularizou.
No pode ser armazenado em cache, pois o SOAP usa o mtodo HTTP POST, o que
considerado no seguro, como vimos esse mtodo pode alterar os dados de um
recurso.

40

VII Concluso

preciso ter cuidado ao apontar uma tecnologia como sendo superior a outra. Geralmente
somos levados pelo modismo e seguimos a tendncia, sem ter um embasamento que justifique
a nossa escolha. O intuito desse trabalho foi demonstrar a funcionalidade das abordagens que
so mais utilizadas nos servios web. claro que dentro do contexto em que estamos
inseridos, uma tecnologia pode levar vantagens em relao a outra, conforme foi demonstrado
no captulo anterior.
Podemos concluir que a melhor escolha estar atrelada ao cenrio em que estamos inseridos.
Talvez a nossa escolha dentro de um contexto no seja a mais adequada em outro.

41

REFERNCIAS BIBLIOGRFICAS

RICHARDSON, S. R. L. RESTful Servios Web. [S.l.]: OReilly Media, 2007.

FIELDING, R. Architectural Styles and the Design of Network-based Software Architectures.
Tese (Doutorado) UNIVERSITY OF CALIFORNIA, IRVINE, 2000.
GOMES, D. A. Web Services SOAP em Java: Novatec, 2010.
HYPERTEXT Transfer Protocol - HTTP/1.1 (RFC 2616 Fielding, et al). Disponvel em:
http://www.w3.org/Protocols/rfc2616/rfc2616.html. Acesso em: 14 set. 2011.
EXTENSIBLE Markup Language (XML). Disponvel em: http://www.w3.org/XML/.
Acesso em: 14 set. 2010.
UNIFORM Resource Identifier (URI): Generic Syntax. Disponvel em:
http://labs.apache.org/webarch/uri/rfc/rfc3986.html. Acesso em: 14 set . 2011.
SIMPLE Object Access Protocol (SOAP). Disponvel em:
http://www.w3schools.com/soap/.Acesso em 14 set. 2011.
WEB Services. Disponvel em: http://www.w3schools.com/webservices/.
Acesso em 14 set. 2011.
UNIVERSAL Description Discovery and Integration (UDDI). Disponvel em:
http://www.w3schools.com/uddi/. Acesso em 14 set. 2011.
REMOTE Procedure Call RPC. Disponvel em:
http://saloon.inf.ufrgs.br/twiki-data/Disciplinas/INF01151/ExercicioEmLaboratorio2006-204/rpc.pdf. Acesso em 14 set. 2011