See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/273316362

Web Services – Uma Análise Comparativa

Article · November 2012

CITATION READS
1 850

2 authors, including:

Pablo Rodrigo Gonçalves

Faculdades Claretianas
3 PUBLICATIONS   2 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Pablo Rodrigo Gonçalves on 09 March 2015.

The user has requested enhancement of the downloaded file.

 Revista das Faculdades Integradas Claretianas – N. 5 – janeiro/dezembro de 2012

Web Services – Uma Análise Comparativa

Ricardo Frenedoso Da Silva

ricardosilva.hrc@gmail.com
Faculdades Integradas Claretianas

Pablo Rodrigo Gonçalves

prof.pablorodrigo@gmail.com
Faculdades Integradas Claretianas

Resumo
Os Web Services são sistemas de informação que, utilizando um conjunto de tecnologias que são padrões da
Internet, permitem a integração entre outros sistemas de informação, através de troca de mensagens. Esse
artigo tem o objetivo de introduzir a tecnologia de Web Services, os conceitos, as tecnologias e padrões
envolvidos e suas aplicações mais comuns. Além disso, apresentar as duas principais alternativas para o
desenvolvimento de Web Services disponíveis atualmente, o protocolo SOAP e o estilo arquiterural REST,
fazendo uma análise comparativa entre elas, realçando as situações onde as vantagens e desvantagens de cada
uma são mais relevantes.
Palavras-chave: Web Services – REST – SOAP – XML – JSON - SOA.

1 Introdução
No final da década de 90, com a popularização da Internet e do uso dos computadores pessoais, viu-se
uma oportunidade na criação de mecanismos de comunicação entre sistemas de informação, que até então
permaneciam isolados. Para essa finalidade foi criada a tecnologia de Web Services.
De acordo com Kreger (2001), “Um Web Service é uma interface que descreve uma coleção de
operações que são acessíveis pela rede através de mensagens XML padronizadas”. Seu uso permite que
plataformas heterogêneas de software e hardware sejam integradas de forma transparente.
O W3C (2004) define web services da seguinte maneira:

Um Web Service é um sistema de software desenvolvido para permitir interações máquina-

máquina através de uma rede. É uma interface descrita para ser consumida por máquinas
(WSDL). Outros sistemas interagem com o Web Service através de mensagens SOAP, geralmente
enviadas através de HTTP em conjunto com outros padrões relacionados à web (W3C, 2004).

Os Web Services permitem que sistemas desenvolvidos em várias linguagens, sendo executados em
diversas plataformas, transmitam e recebam informações padronizadas entre si, permitindo uma interação
máquina-máquina mais abrangente que qualquer outra tecnologia de computação distribuída existente.
Essa independência de protocolo e plataforma é conseguida através da utilização de interfaces. Toda a
comunicação é realizada através da chamada de métodos do serviço, e do envio e recebimento de mensagens
padronizadas. Dessa forma, os Web Services permitem
que as aplicações sejam integradas mais rapidamente, facilmente e com menor custo do que nunca (KREGER,
2001).
Permitir que uma aplicação consuma um serviço disponibilizado através de um Web Service sem
conhecer os detalhes internos desse serviço cria um encapsulamento que traz inúmeros benefícios, como a
reutilização de código e, consequentemente, a simplificação dos sistemas. É possível, por exemplo, utilizar os
serviços de geolocalização do Google (Google Maps API) através de seu web service, sem conhecer os detalhes
da codificação, estruturas de dados, lógica do processamento, etc. É possível também utilizar Web Services
para publicar ou integrar sistemas legados com novos sistemas em desenvolvimento, de forma a reutilizar a
base de código e de regras de negócio que já estão em produção, criando novas formas de visualização dos
dados. Web services também são utilizados na construção de sistemas multicamadas, arquitetura que divide o

7
 Web Services – Uma Análise Comparativa

sistema em vários módulos lógicos, com responsabilidades distintas e com baixo acoplamento entre si,
permitindo que uma camada seja alterada ou substituída sem afetar outras partes do sistema.

2 Arquitetura Orientada a Serviços (SOA)

O termo SOA (Service Oriented Architecture) surgiu para designar um conjunto de arquiteturas e
padrões de desenvolvimento de software focados na disponibilização e consumo de serviços entre aplicativos
em uma rede. O W3C (2004) define SOA como “um conjunto de componentes que podem ser invocados, e cuja
interface pode ser publicada e descoberta.”. Cada componente da arquitetura SOA representa um serviço, ou
uma funcionalidade específica do sistema. Um serviço pode consumir outro serviço, utilizando uma
funcionalidade que já foi implementada, permitindo a criação de serviços mais simples como uma validação de
CPF, até serviços mais complexos.
O aplicativos consumidores utilizam o serviço sem se preocupar com a sua implementação, apenas
acessando uma interface comum que esconde os detalhes do modelo de dados e do processamento realizado. O
servidor por outro lado, não se preocupa com quais aplicativos consomem seus serviços.
A tecnologia de Web Services é parte importante da arquitetura SOA, e permite que serviços sejam
desenvolvidos, publicados, descobertos e consumidos de uma forma simples e robusta.

3 Sistemas multicamadas
A divisão em camadas é uma técnica muito utilizada pelos engenheiros de software para implementar
um sistema de software complexo (FOWLER, 2002). Separando o sistema em camadas, o entendimento é
facilitado, pois cada camada é responsável por prover uma funcionalidade restrita e bem definida. O
acoplamento também é reduzido, uma vez que cada camada está acoplada somente à camada imediatamente
superior e inferior, provendo serviços para a primeira e consumindo serviços da segunda.
Inicialmente os sistemas de gestão empresarial, e vários outros sistemas cujo objetivo fosse
armazenar, ler e processar informações em um banco de dados, eram construídos de forma que os códigos da
interface visual, das regras de negócio e da persistência no banco de dados eram escritos na mesma unidade
de código (arquitetura cliente/servidor). Sendo assim, as camadas de visualização, lógica e persistência
estavam fortemente acopladas. Apesar de funcionar bem para pequenos projetos, para sistemas maiores isso
se torna um grande problema, pois qualquer alteração em qualquer uma das camadas interfere diretamente
nas outras, causando alterações em cascata. Com o uso de Web Services é possível implementar cada camada
separadamente, facilitando a manutenção e aumentando a performance geral da aplicação

4 O Protocolo SOAP
A integração de um aplicativo cliente com um Web Service deve ocorrer através da troca de
mensagens. Para que possa haver uma comunicação entre duas máquinas, é necessário que haja uma conexão
física entre elas pela qual os dados irão trafegar, além de um protocolo de comunicação comum, para que
ambos os lados consigam interpretar as mensagens recebidas e saibam como formar as mensagens que serão
enviadas como resposta.
O protocolo SOAP define um padrão para essa troca de mensagens, que são documentos XML especiais.
SOAP também especifica uma linguagem para a descrição dos métodos disponibilizados pelo serviço (WSDL),
além da especificação de um serviço de descoberta de Web Services (UDDI). Sua especificação foi desenvolvida
e publicada pelo W3C (consórcio de empresas, entre elas IBM, Amazon e Microsoft, responsável pela
especificação de várias tecnologias da Web).

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 8

 Web Services – Uma Análise Comparativa

SOAP é uma recomendação do W3C, o que significa que é um padrão que já passou por um longo
processo de avaliação e testes. SOAP é um framework composto, padronizado e extensível para o
empacotamento e troca de mensagens XML (W3C, WSA pag 65).
O protocolo SOAP é um protocolo stateless, ou seja, não mantém estado entre as mensagens enviadas
e recebidas. Cada mensagem deve conter todas as informações necessárias para que seja processada. SOAP é
flexível o suficiente para ser utilizado em aplicações que utilizem o padrão requisição/resposta,
requisição/múltiplas respostas, etc.

5 O documento WSDL
O documento WSDL (Web Service Description Language) é o contrato estabelecido entre o Web Service
e seus clientes. É um documento XML que fornece informações detalhadas a respeito do serviço publicado,
necessárias para que os aplicativos cliente consigam consumi-lo.
Existem ferramentas que utilizam o WSDL para gerar código de apoio, facilitando o consumo do serviço.
Na maioria dos casos, o desenvolvedor não precisa trabalhar diretamente com SOAP, a infraestrutura do SOAP
fica em uma camada inferior à da aplicação, facilitando o desenvolvimento.
O WSDL da versão 1.1 do SOAP está dividido em 5 seções.
A seção types é opcional, e contém definições sobre os tipos de dados utilizados nas chamadas dos
métodos. Geralmente essa seção aponta, ou contém, um documento do tipo XSD, que serve para validar a
estrutura de um XML.
Na seção message são declaradas todas as mensagens que implementam o serviço. Essas mensagens
são formadas pelos tipos definidos na seção anterior, ou utilizam-se dos tipos básicos padrões, como String e
Integer.
A seção portType reúne as mensagens para formar operações, repetindo várias informações da seção
anterior. Cada operação é vinculada a uma mensagem de entrada (input) e saída (output).
A seção binding é a seção mais complexa do WSDL. Nessa seção, a definição das operações se torna
mais concreta. É definido o protocolo de transporte (HTTP, SMTP, etc), o estilo do serviço (RPC ou Document) e
o formato dos dados (literal ou encoded).
Por fim, a seção service possui informações como nome e localização real do serviço, os endpoints, nos
quais as operações descritas estão disponíveis para acesso.

6 Mensagens SOAP
Para requisitar a executação de uma operação, o aplicativo envia um documento XML que contém uma
mensagem SOAP. Essa mensagem contém uma estrutura própria e é construída pela biblioteca SOAP do cliente
com base na inspeção do WSDL do serviço.
Uma mensagem SOAP possui três partes, uma delas sendo opcional: Envelope, Header (opcional) e
Body.

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 9

 Web Services – Uma Análise Comparativa

Figura 1 - Estrutura de uma mensagem SOAP (KALIN, 2009)

A tag Envelope envolve toda a mensagem, delimitando seu começo e fim, e contém as declarações de
namespace. É a tag raiz da mensagem.
A seção Header é opcional, e permite que informações adicionais sejam carregadas pela mensagem, até
o servidor. Nessa seção podem ser inseridas informações de autenticação, autorização, assinatura digital, etc.
O header também é utilizado nas arquiteturas distribuídas baseadas em SOAP, onde a mensagem é processada
por vários nós antes de alcançar o destinatário final. Assim, os nós podem ler e alterar os dados do cabeçalho
da mensagem, sem alterar seu conteúdo.
A seção body contém o corpo da mensagem. Nessa seção é inserido o conteúdo que será entregue ao
destinatário final da mensagem. Em uma mensagem de requisição de um serviço, é enviado no corpo da
mensagem o nome da operação solicitada, conforme descrito no WSDL, e o valor dos parâmetros, caso haja
algum. Na mensagem de retorno do serviço, é enviado o nome da operação, seguido do resultado processado.
No final da mensagem há uma seção reservada para o envio de anexos SOAP, que pode ser uma
sequência muito longa de caracteres, um arquivo, uma imagem, etc.
A mensagem abaixo é um exemplo de requisição SOAP. No corpo da mensagem existe uma tag
especificando qual função deve ser executada (getFuncionarios).
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:web="http://webservices/">
<soapenv:Header/>
<soapenv:Body>
<web:getFuncionarios/>
</soapenv:Body>
</soapenv:Envelope>

A próxima mensagem é a resposta da função getFuncionarios requisitada anteriormente. Interno a tag

getFuncionariosResponse, o servidor envia uma lista de funcionários, na forma de um documento XML.
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 10

 Web Services – Uma Análise Comparativa

<S:Body>
<ns2:getFuncionariosResponse xmlns:ns2="http://webservices/">
<return>
<dataNascimento>20/03/1975</dataNascimento>
<departamento>TI</departamento>
<nome>Carlos</nome>
<RE>52258</RE>
<sobrenome>Oliveira</sobrenome>
</return>
<return>
<dataNascimento>13/05/1981</dataNascimento>
<departamento>Contabilidade</departamento>
<nome>Pedro</nome>
<RE>33558</RE>
<sobrenome>Teodoro</sobrenome>
</return>
<return>
<dataNascimento>21/10/1978</dataNascimento>
<departamento>TI</departamento>
<nome>Jorge</nome>
<RE>33665</RE>
<sobrenome>Pereira</sobrenome>
</return>
<return>
<dataNascimento>31/11/1971</dataNascimento>
<departamento>Vendas</departamento>
<nome>Eduardo</nome>
<RE>32155</RE>
<sobrenome>Pires</sobrenome>
</return>
</ns2:getFuncionariosResponse>
</S:Body>
</S:Envelope>

7 O Estilo Arquitetural REST

O protocolo SOAP é uma tecnologia viável e com um grande suporte entre as linguagens de
programação atuais, porém é consenso entre os especialistas que em alguns aspectos o protocolo SOAP foi
projetado em excesso. Esse é um dos motivos pelo qual os Web Services de estilo REST vem ganhando cada
vez mais notoriedade entre os desenvolvedores de Web Services. Empresas como Google, Facebook, Twitter e
Amazon já disponibilizam Web Services de estilo REST para acesso aos seus serviços.
REST significa Representational State Transfer (Transferência de Estado Representacional) e sua
especificação foi criada por Roy Fielding em sua dissertação de pós-doutorado, no ano 2000. É um estilo
híbrido, derivado de vários estilos arquiteturais baseados em rede (FIELDING, 2000). REST não é uma

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 11

 Web Services – Uma Análise Comparativa

tecnologia, nem um protocolo. É um conjunto de princípios que, conforme são implementados no projeto de
software, trazem consigo algumas vantagens e restrições.
Segundo Fielding (2000), um estilo arquitetural é um conjunto de regras que restringe os
papéis/funcionalidades dos elementos arquiteturais e o grau de relacionamento entre esses elementos nas
arquiteturas que aplicam esse estilo. Definir estilos de arquitetura de software é um recurso útil, pois permite
nomear um conjunto de padrões, técnicas e regras de forma que seja fácil identificá-los, discutir
melhoramentos e aplicá-los de forma efetiva no desenvolvimento de projetos de software.
O estilo REST foi projetado de forma a utilizar ao máximo a arquitetura da Web existente, tirando o
maior proveito possível dos protocolos e tecnologias que já estão em uso desde que a world wide web foi
criada. Roy Fielding foi um dos principais autores da especificação do protocolo HTTP (Hyper Text Transfer
Protocol), o protocolo de envio e recebimento (solicitação e resposta) de mensagens predominante na web.
Quando Fielding nomeou o estilo como Transferência de Estado Representacional, ele se referia ao
modo como a Web funciona. A Web é um conjunto de páginas disponíveis na Internet, conectadas entre si
através de hyperlinks. Ao acessar uma dessas páginas através de seu endereço (URL, ou URI), o usuário recebe
uma representação dessa página. Clicando em um link dessa página, o estado é transferido para a nova página,
e o usuário recebe uma nova representação.
Um Web Service de estilo REST é formado por um conjunto de Recursos, onde cada recurso possue um
identificador único. Esses recursos possuem uma ou mais representações, estão conectados através de
hyperlinks, e possuem métodos que permitem a manipulação das suas representações.
Os serviços baseados em REST são nomeados pelos desenvolvedores conforme o grau de aderência aos
princípios da arquitetura. Web Services que implementam todas as diretrizes do estilo são chamados de Web
Services Restful. Os que implementam somente parte das diretrizes, são chamados de Restlike.

7.1 O protocolo HTTP

O protocolo HTTP (Hyper Text Transfer Protocol), traduzido como Protocolo para Transferência de
Hipertexto, é o protocolo mais antigo e o mais utilizado na Internet. Através dele é possível requisitar uma
página web, enviar um formulário preenchido, fazer upload de arquivos, etc.
A definição do W3C, no documento de especificação do HTTP, é bem clara:

O protocolo de Transferência de Hypertexto é um protocolo de nível de aplicação para sistemas

de informação distribuídos, colaborativos e baseados em hipermídia. É um protocolo genérico,
stateless, que pode ser usado para diversas finalidades além de seu uso com hypertexto, como
servidores de nomes e sistemas de gerenciamento de objetos distribuídos, através da extensão
de seus métodos, códigos de erro e cabeçalhos. Um dos recursos do HTTO é a tipagem e a
negociação da representação dos dados, permitindo que sistemas o utilizem independentemente
dos dados que serão transferidos (W3C, 1999a).

É um protocolo baseado na arquitetura requisição-resposta. Para cada requisição que o browser envia
para um servidor, há uma resposta. HTTP não é orientado a conexão e não mantém estado entre as chamadas.
Isso significa que toda informação necessária para que uma requisição seja processada deve ser passada na
própria requisição. Essa abordagem promove uma maior escalabilidade, pois os recursos não ficam alocados no
servidor por muito tempo.
Uma requisição HTTP consiste em um cabeçalho e, opcionalmente, um corpo. O cabeçalho HTTP é um
conjunto de linhas, no formato chave:valor, e é enviado em texto puro.
Uma típica requisição HTTP possui o seguinte formato:
GET localhost/pagina.html HTTP/1.1
accept:text/html

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 12

 Web Services – Uma Análise Comparativa

user-agent: IE/6.0
if-modified-since: Sat, 24-01
cookie: user=joao

A palavra GET indica o verbo, ou comando, que será utilizado para na requisição. Existem vários verbos
na especificação do HTTP, os mais utilizados são:
GET: solicitação simples de um recurso ao servidor.
POST: solicitação uma gravação em um recurso no servidor.
PUT: criar um recurso no servidor.
DELETE: requisição para deleção de um recurso.
HEAD: Semelhante ao método GET, exceto que o recurso não é transferido para o cliente, apenas uma
confirmação de recebimento. Serve para testar a disponibilidade de uma URL.
Em seguida temos o domínio, o host para o qual a solicitação será enviada. Ainda na primeira linha do
cabeçalho é incluída a versão do protocolo utilizada para a requisição.
O parâmetro accept permite que o cliente especifique o formato desejado da resposta. Entre os valores
possíveis estão text/xml para receber documentos XML, image/jpeg para imagens, e text/json para repostas
utilizando a notação JSON, entre outros.
A resposta também possui um cabeçalho e possivelmente um corpo, utilizado para transmitir os dados
do processamento realizado. O exemplo a seguir é uma resposta HTTP:
HTTP/1.0 200 Ok
date: Sat, 24 Jan 2004 23:58:
content-type: text/html
set-cookie: user=fred
<html><head><title>Título da página</title
<body>
</body>
</html>

A primeira linha do cabeçalho de resposta contém, respectivamente, a versão do protocolo e um código

de status. Esses códigos são utilizados para informar ao cliente se uma requisição foi processada com sucesso
ou se ocorreu algum erro. No caso, o código “200 Ok” significa que a requisição foi bem-sucedida.

8 Recursos
A noção de recursos é o conceito central do estilo REST. Se traçarmos um paralelo com o mapeamento
relacional de um banco de dados, podemos dizer que os recursos em REST equivalem às Entidades do modelo
relacional. Recursos são coisas, substantivos, objetos que são disponibilizados pelo serviço.
“Um recurso é qualquer informação que pode ser nomeada. É um mapeamento conceitual para um
conjunto de Entidades, não uma Entidade que corresponde a um mapeamento em um determinado ponto do
tempo.” (FIELDING, 2000).
Podemos considerar como exemplos de recursos o conjunto de alunos de uma sala de aula, um
determinado aluno dessa mesma sala, um serviço de previsão do tempo, o acervo histórico da cidade de São
Paulo, etc. Ao dizer que um recurso é um mapeamento para uma entidade, e não uma entidade em um
determinado ponto no tempo, Fielding quer dizer que os dados, as informações de um determinado recurso,
podem variar em função do tempo, mas isso não significa que cada variação se torna um recurso distinto.

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 13

 Web Services – Uma Análise Comparativa

A World Wide Web nada mais é do que uma coleção de recursos, nesse caso documentos HTML, que
são referenciados entre si através de hyperlinks. A página do New York Times por exemplo, pode ser
considerada um recurso, e pode possuir uma representação diferente quando acessada em diferentes dias e
horários.
Ao contrário de SOAP, que é por si só um protocolo de envio e recebimento de mensagens, REST não
define como as mensagens são enviadas e recebidas. Ao invés disso, ele utiliza o próprio protocolo HTTP.
Cada recurso deve possuir um identificador único, que será utilizado como interface para acesso ao
recurso. Utilizando-se novamente do protocolo HTTP, um web service REST utiliza URLs para identificar seus
recursos. Essa abordagem garante que os identificadores dos recursos sejam únicos globalmente, uma vez que
está atrelado a um domínio da web.
O mapeamento de Recursos para URLs em serviços de estilo REST são estruturados da seguinte
maneira: em um serviço de exemplo que tem a funcionalidade de fornecer uma lista de funcionários, e que está
hospedado na máquina local, a URL para acessar tal lista seria por exemplo
http://localhost/meuservico/funcionarios. Nesse contexto, http é o protocolo utilizado, localhost é o domínio
onde o serviço está hospedado, meuservico é o nome do Web Service, e funcionarios é o nome do recurso
acessado. Uma solicitação HTTP para essa URL retornaria uma lista de funcionários cadastrados no sistema que
o serviço expõe.
Para acessar os dados de um determinado funcionário, supondo que exista um campo chamado RE
(Registro do Empregado), que identifique na base de dados cada funcionário unicamente, esse campo passa a
fazer parte da URL, ficando da seguinte forma: http://localhost/meuservico/funcionarios/2334, onde 2334 é
número de RE do funcionário do qual se deseja obter os dados.
Caso fosse necessário requisitar a lista de dependentes de um determinado funcionário, a URL do
serviço ficaria parecida com http://localhost/meuservico/funcionarios/2334/dependentes. Seguindo o mesmo
padrão de mapeamento, se o objetivo fosse listar as informações de um determinado dependente, o
mapeamento seria http://localhost/meuservico/funcionarios/2334/dependentes/33115544469, onde
33115544469 seria, por exemplo, o número do CPF do dependente, campo que o identificaria unicamente no
conjunto.
Aqui existe uma diferença substancial entre o protocolo SOAP e o estilo REST. Enquanto o primeiro
publica funções (verbos), métodos que podem ser invocados e retornam um resultado, de forma muito parecida
com os sistemas RPC de outrora, o segundo publica um conjunto de recursos (substantivos), entidades, que
possuem representações que são transferidas entre as chamadas.

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 14

 Web Services – Uma Análise Comparativa

Figura 2 - Exemplo de mapeamento de um recurso em um serviço REST. (KALIN, 2009)

9 Representações
De acordo com Fielding (2000), “uma representação consiste de dados, metadados para descrever os
dados e, quando necessário, metadados para descrever os metadados (geralmente para o propósito de verificar
a integridade das mensagens)”. A representação de um recurso é utilizada para capturar seu estado atual ou
indicar seu estado desejado, para que seja possível transferir essa representação entre os componentes
envolvidos.
São essas representações dos recursos que são transferidas para o cliente do serviço, e não o recurso
em si. Elas podem ser exibidas, processadas, e enviadas novamente para o serviço.
Cada recurso pode possuir uma ou mais representações. Ao acessar o recurso de listagem de
funcionários citado anteriormente, o cliente pode solicitar as informações de um funcionário representadas em
um documento XML, em um arquivo CSV (campos separados por vírgula), uma página HTML com os dados já
formatados, ou uma imagem, que contenha a foto 3x4 do funcionário.
Se um cliente solicitar o recurso http://localhost/meuservico/funcionarios/2334, sugerindo XML como
representação, obteria o seguinte documento:
<funcionarios>
<funcionario href="http://localhost/meuservico/funcionarios/2334">
<RE>2334</RE>
<nome>José Carlos de Oliveira</nome>
<dataNascimento>29/01/1986</dataNascimento>
</funcionario>
</funcionarios>

Esse tipo de resposta se parece muito com uma resposta obtida de um Web Service baseado em SOAP.
A principal diferença é que o documento SOAP conteria, além dos dados requisitados, informações de controle
da mensagem SOAP, aumentando o tamanho da mensagem.

9.1 JSON

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 15

 Web Services – Uma Análise Comparativa

Um documento XML precisa posicionar a informação entre tags personalizadas, que possuem um nome
que identifica a informação. Dessa forma, se a informação a ser transmitida for muito variada em termos de
número de campos, haverá um aumento considerável no tamanho das mensagens transmitidas (CROCKFORD,
2006).
Um dos formatos mais adotados nos serviços de estilo REST é o formato JSON, que é a sigla para
JavaScript Object Notation (Notação de Objetos JavaScript).
JSON é um formato leve, independente de máquina, baseado em texto, utilizadao para troca de dados e
serialização de Objetos. É derivado da declaração literal de objetos da linguagem JavaScript (IETF, 2006). A
principal vantagem de JSON sobre XML é o tamanho do arquivo. JSON é muito mais compacto, e ainda
consegue ser autodescritivo, utilizando uma notação de pares chave/valor para descrever os campos.
Com JSON é possível representar 4 tipos primitivos: números, strings, booleanos e null; e dois tipos
estruturados: array e objeto. Abaixo está um exemplo de um objeto funcionário serializado utilizando a notação
JSON:
{
"funcionario": {
"RE": 2334,
"nome": "Jose Carlos",
"sobrenome": "Oliveira",
"departamento": "Produção",
"ativo": true,
"dataNascimento": "2011-09-23"
}
}

9.2 Hipermídia
O conceito de hipermídia está diretamente relacionado aos conceitos de Recurso e Representação. É
através dos hyperlinks que se torna possível descobrir e requisitar as representações dos diversos recursos
disponíveis em um serviço de estilo REST.
Um link, também citado como Web Link ou hyperlink, é uma conexão entre um recurso da Web e outro
e, apesar de ser um conceito simples, é uma das principais características responsáveis pelo sucesso da Web
(W3C, 1999b).
Esse é um aspecto que diferencia o estilo REST da maioria das arquiteturas de sistemas distribuídos,
onde os dados são encapsulados e ocultados pelos componentes de processamento. Em um sistema baseado
em hipermidia, quando um link é acessado são os dados que se movem de uma localização a outra. (FIELDING,
2000).
Ao acessar uma página na Web, essa página é renderizada no browser do usuário, e pode conter
diversos recursos, como textos, figuras, animações, e hyperlinks, que quando clicados, direcionam o usuário
para outra página, outro recurso.
No estilo REST, os hyperlinks possuem exatamente a mesma função que possuem na Web:
conectar um recurso ao outro.
Isso permite que, uma vez que o aplicativo que está consumindo o serviço tenha acesso à
representação de um recurso, essa representação contenha, além dos dados do estado atual do recurso, links
para recursos relacionados, ou para outras representações do mesmo recurso.

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 16

 Web Services – Uma Análise Comparativa

Os links para os recursos relacionados são incluídos na representação do recurso. Utilizando o exemplo
do capítulo anterior, ao requisitar uma lista de funcionários, a representação poderia conter apenas informações
básicas sobre cada funcionário, e um link para a URL onde seria possível obter uma representação completa de
cada registro.

9.3 Verbos HTTP aplicados aos recursos

Em um Web Service de estilo REST, os recursos disponibilizados são substantivos, pois representam
algum objeto, seja ele concreto ou abstrato. Sendo assim, para executar ações nesses substantivos é
necessária a aplicação de verbos, como ocorre nos diversos idiomas falados no mundo.
Nos idiomas, alguns verbos são específicos e só podem ser utilizados por um conjunto restrito de
substantivos. Sentenças como acelerar um lápis ou navegar um carro não fazem sentido. Por outro lado,
existem alguns verbos que podem ser aplicados a praticamente todos os substantivos, como pegar, criar e
colocar.
REST utiliza os verbos padrão existentes no protocolo HTTP para permitir que operações sejam
realizadas sobre os seus recursos. Conforme afirma Kalin(2009), no núcleo da arquitetura REST está a noção
de que o HTTP, apesar da palavra transporte em seu nome, é uma API, e não apenas um protocolo de
transporte.
Fielding nomeia essa característica de Interface Uniforme. Utilizando os verbos padrão do HTTP, cada
recurso pode ser acessado e manipulado através da mesma interface. Mesmo que os métodos possuam
significados diferentes quando aplicados a recursos diferentes, isso não depende de uma implementação
específica, apenas a semântica da operação é alterada, a sintaxe permanece a mesma.
Seguindo esse raciocínio e aproveitando a estrutura do protocolo HTTP existente, o estilo REST utiliza
os verbos HTTP como operações sobre os recursos. Cada verbo padrão é mapeado para uma ação específica,
conforme o seguinte padrão:
O verbo GET é utilizado para requisitar uma representação do recurso. No cabeçalho da requisição,
mais especificamente no parâmetro accept, o requisitante sugere o formato desejado da representação.
POST é usado para criar um novo recurso, ou executar uma operação. Os dados do novo recurso são
enviados no corpo da requisição.
O verbo PUT é usado para atualizar um recurso existente. Novamente, os dados alterados do recurso
são enviados na requisição.
Por fim, o verbo DELETE é utilizado para apagar um recurso.
Esse é um grande diferencial entre SOAP e REST. Por ser um protocolo totalmente independente, SOAP
ignora as funcionalidades do HTTP, e precisa exportar cada funcionalidade como um novo método. Além disso,
uma mensagem SOAP é enviada geralmente por HTTP, que também serve como protocolo de transporte,
criando uma redundância desnecessária, ao encapsular um protocolo dentro de outro.
Utilizando essa abordagem, os serviços REST se aproveitam da estrutura pronta do HTTP, e torna
possível mapear qualquer ação que esteja disponível em um recurso, ou em um conjunto de recursos.

10 Conclusão
Decidir quais tecnologias utilizar em novos projetos de software está entre as decisões mais difíceis da
equipe de desenvolvimento, e possui influência direta no andamento do projeto, sendo determinante para seu
sucesso ou fracasso.
SOAP é o padrão estabelecido de mercado e tem o apoio de empresas que estão na vanguarda da
tecnologia de computação, como Oracle, IBM e Microsoft. Possui mais ferramentas de apoio ao desenvolvedor e

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 17

 Web Services – Uma Análise Comparativa

várias extensões que permitem a adição de funcionalidades ao protocolo, como criptografia das mensagens,
autenticação e autorização de usuários, mensagens assíncronas, etc. Por outro lado, é um protocolo extenso,
com muitos detalhes, e praticamente impossível de se trabalhar sem apoio de ferramentas auxiliares.
Ao utilizar a estrutura da web existente, o estilo REST leva vantagem em diversos aspectos, como
diminuição do tráfego na rede, criação de APIs mais intuitivas e a utilização de uma interface única.
De fato, nenhuma tecnologia irá substituir a outra, pelo menos não a médio prazo. Cada abordagem
apresenta situações onde se encaixam melhor e problemas que solucionam de forma mais elegante.
Cabe ao arquiteto de software analisar detalhadamente cada requisito da aplicação a ser desenvolvida,
e comparar com as opções disponíveis, de forma a tomar a melhor decisão possível.

11 Referências Bibliográficas
CROCKFORD, D. JSON: The Fat-Free Alternative to XML. 2006. Disponível em http://www.json.org/fatfree.html.
Acesso em Novembro 2011.
FIELDING, Roy Thomas. Architetural Styles and the Design of Netword-based Software Architetures. 2000.
Dissertação (Doutorado em Filosofia da Computação). Universidade da Califórnia. Irvine.
FOWLER et al. Patterns of Enterprise Application Architecture. 2002. Addison Wesley. 560p.
IETF. The application/json Media Type for JavaScript Object Notation (JSON). 2006. Disponível em
http://www.ietf.org/rfc/rfc4627.txt?number=4627. Acesso em Novembro de 2011.
KALIN, Martin. Java Web Services: Up and Running. 1st Edition. 2009. O’Reilly Media, Inc. 336p. (tradução
nossa).
KREGER, Heather. Web Services Conceptual Architecture (WSCA 1.0). 2001. IBM Software Group. Disponível
em http://www.ibm.com/software/solutions/webservices/pdf/WSCA.pdf. Acesso em: 01/05/2011.
SUDA, Brian. SOAP Web Services. 2003. University of Edinburgh.
TANENBAUM, A. S.; STEEN, M. V. Distributed Systems: Principles and Paradigms. Pearson Prentice Hall, 2008.
UFCG. Introdução e Motivação: Arquiteturas em N Camadas. 2005. Universidade Federal de Campina Grande.
Disponível em: http://www.dsc.ufcg.edu.br/~jacques/cursos/j2ee/html/intro/intro.htm. Acesso em
18/11/2011.
W3C. HTML 4.01 Specification. 1999a .Disponível em http://www.w3.org/TR/html4/cover.html. Acesso em
Novembro 2011.
W3C. Hypertext Transfer Protocol HTTP/1.1. 1999b. Disponível em
http://www.w3.org/Protocols/rfc2616/rfc2616.html. Acesso em 17/11/2011.
W3C. Web Services Architecture. 2004. Disponível em http://www.w3.org/TR/2004/NOTE-ws-arch-20040211.
Acesso em Agosto 2011.

Revista das Faculdades Integradas Claretianas – Nº5 – janeiro/dezembro de 2012 18

 Web Services – Uma Análise Comparativa

Revista das Faculdades Integradas Claretianas – Nº4 – janeiro/dezembro de 2011 19

View publication stats