COMPARANDO APLICAO WEB SERVICE

REST E SOAP

Cleber de F. Ferreira, Roberto Dias Mota.

Universidade Paranaense (Unipar)
Paranava PR Brasil
cleberferreirasi@hotmail.com, motaroberto@hotmail.com

Resumo. Este artigo descreve o que um Servio, usualmente conhecido

como Web Services e compara dois tipos de arquiteturas de web services:
SOAP (Simple Object Data Protocol) e REST (Representational State
Transfer). Existem defensores de ambas as arquiteturas. No decorrer do estudo
veremos exemplos das duas arquiteturas e suas caractersticas e diferenas.

1. Introduo

Segundo Abinader Nelo e Lins (2006), Varias tecnologias surgiram nos ltimos anos
destinadas ao desenvolvimento de aplicaes para a Internet. Contudo estas possuem
suas limitaes e particularidades, que impede a troca de informaes de forma
automatizada.

O conceito de Web services, ou melhor, de servios em uma aplicao existe j

algum tempo. Servios, assim como componentes, so considerados blocos de
construo independentes, que coletivamente representam um ambiente de aplicao.
Entretanto, diferente de componentes tradicionais, servios tm algumas caractersticas
nicas que lhes permitem participar como parte de uma arquitetura orientada a servios.
E uma das principais caractersticas a completa autonomia em relao ao outros
servios. Isto Significa que cada servio responsvel por seu prprio domnio, que
limita seu alcance a uma funo de negcio especfico.

J sobre a arquitetura SOAP versos REST, Apesar de terem abordagens

diferentes, so capazes de disponibilizar os mesmos servios deixando para o
desenvolvedor a responsabilidade de escolher qual entre as duas usar.

O objetivo deste artigo, mostrar as principais caractersticas de ambas

arquiteturas SOAP e REST, de forma relevante.

2. Metodologia

Neste trabalho foi realizada extensa reviso bibliogrfica, tanto em revistas eletrnicas,
livros e site do assunto na Internet. Foi implementado posteriormente ao artigo um
prottipo simplificado para evidenciar as caratersticas de ambas arquiteturas.
3. Desenvolvimento

3.1. O que um Servio ou Web Services

Temos hoje a possibilidade de reutilizar processos e no apenas cdigos. Podemos

construir aplicaes para determinado fim e fazer com que outras aplicaes reutilizem
seus processos. Com isto, minimizamos a preocupao de usar o cdigo da aplicao
novamente, e ao invs disso, reutilizamos aplicao como um servio. De acordo com a
[W3C] - Word Wide Web Consortium Organizao internacional que rege os padres
de tecnologia utilizada na internet, web service um software projetado para suportar
interao mquina-a-mquina interoperveis sobre uma rede. Utilizando uma interface
de formato processvel.

Em termos prticos, web service uma arquitetura de comunicao entre

software que sejam da mesma plataforma ou no. A caracterstica marcante dessa
arquitetura que a comunicao sempre realizada em rede e deve estar sempre
disponvel. Vale salientar que a internet a rede que conecta todas as outras redes, ou
seja, est arquitetura fornece alcance global de comunicao entre quaisquer aplicativos.

3.1.1. Benefcios do web services

Protocolos baseados em um padro com o XML - (Extensible Markup Language),

permitindo a gerao automtica tanto do cdigo cliente quanto do cdigo servidor;

Utilizao de protocolos baseados em texto, o que permite trfego suave atravs

de firewalls que fazem verificaes de pacotes;

Utiliza porta 80 do protocolo HTTP - (HyperText Transfer Protocol), o que

permite transportar as chamadas ao servio sem que o firewall bloqueie;

Distribuio de cdigo de forma modularizada que permite fcil manuteno e

correo de erros, sem os problemas verificados com as verses binrias de arquiteturas
distribudas;

Com a modularizao atingida no item interior, torna-se possvel que

dispositivos de diferentes arquiteturas como computadores, handhelds, telefones
celulares, entres outros, consigam interagir e reutilizar servios e pores de cdigos
possibilitando um uso mais inteligente e eficiente dos recursos computacionais.

3.2. Arquitetura SOAP

Segundo [David Chappell e Tyler Jewell, 2002], a especificao SOAP descreve quatro
componentes principais: a formatao de convenes para encapsular dados e
orientaes de rota na forma de um envelope, um transporte ou protocolo
obrigatoriamente, regras de codificao, e um mecanismo de RPC - (Remote Procedure
Call). O envelope define uma conveno para descrever o contedo de uma mensagem,
a qual, por sua vez tem implicaes na forma como processado. Um protocolo de
ligao proporciona um mecanismo genrico para o envio de um envelope SOAP por
meio de um protocolo de baixo nvel, tais como HTTP. Regras de codificao
proporciona uma conveno para mapear vrios tipos de dados da aplicao, para uma
representao baseada em tag XML. Finalmente, o mecanismo de Chamada
Procedimento Remoto RPC, que fornece uma maneira para representar chamadas de
procedimento remoto e seus valores de retorno. Na figura 1 exibimos um exemplo de
arquitetura Web service SOAP.

Figura 1 - Java Web Services Up and Running, Martin Kalin.

De modo a facilidar o entendimento a figura 2 abaixo, chamaremos a aplicao

que solicita o servio de AppClient, e a que prov o servio de AppServer. Nela
podermos observar o ciclo de funcionamento do web service que utilizam a arquitetura
SOAP. Primeiro a AppClient localizado em um host, computador, notebook ou
dispositivo mvel envia uma requisio HTTP atravs da rede para a AppServer que
disponibiliza o web service localizada e um servidor ou em um simples desktop
ento AppServer devolve para a AppClient um arquivo WSDL (Web Services
Descreption Language).

Figura 2 Exemplo de Troca de informao Entre um Cliente e Servidor usando tecnologia SOAP.

WSDL um arquivo com formato XML, que informa para a AppClient como
utilizar o servio. Neste arquivo do AppClient encontra-se informaes como nome de
mtodos, nome de parmetros, endereo do servio, como deve ser formatado o arquivo
de entrada e como ser formatado o arquivo de saida. Concluindo enfim, todo o
contedo necessrio para utilizar o servio.
3.2.1. Caractersticas

As principais caractersticas da arquitetura SOAP estabelecer um formato padro de

mensagem que consiste em um documento XML, capaz de hospedar dados RPC e
centrados em documentos. Isto facilita o intercambio de dados de modelos sncronos
(pedido e resposta) e assncronos (orientado a processo). Com o WSDL estabelecendo
um formato de descrio padro para aplicaes, o uso de formato de mensagem
centrada em documento muito comum;

Grande quantidade de contedo textual formatado em XML;

Possui seus prprios protocolos, focado em expor peas lgicas de aplicao

(mtodos) como servios;

Descreve funes, tipo de dados;

Muitas linguagens de programao suportam SOAP de forma nativa;

Cdigos binrios necessita ser transformado usando base64encoded.

3.2.2. Situaes onde usar SOAP

Processamento e chamadas assincronos: se aplicao precisa de um nvel garantido de

confiabilidade e segurana para a troca de mensagens;

Contratos formais: ambos os lados (fornecedor e consumidor) tm que concordar

com o formato de intercambio de dados, onde SOAP fornece especificaes rigidas para
esses tipo de interao;

Operaes stateful: onde a aplicao precisa de informao contextual e

geranciamento de estado com coordeno e segurana

3.3. Arquitetura REST

Figura 3 - Exemplo de Troca de informao Entre um Cliente e Servidor usando tecnologia REST.
Na figura 3 acima, a AppClient envia uma requisio (HTTP Request) contendo as
informaes necessrias para executar uma determinada operao para a AppServer. A
AppServer processa a requisio e devolve para a AppClient uma resposta (HTTP
Response) contendo um arquivo XML ou uma String JSON (Java Script Object
Notation) contendo desde uma simples mensagem a um conjunto de informaes
complexas. O JSON trata-se de um formato leve para intercmbio de dados.

Como podemos observar na arquitetura REST, no existe um descritor de

funcionamento do servio. A requisio realizada pela AppClient parte do principio que
a mesma conhece o que deve ser enviado para AppServer, facilitando assim o processo
de implementao.

JSON um texto que representa um objeto. Este formatado da seguinte

maneira: {texto: valor, texto: valor, ... texto: valor}. Desta maneira possvel
representar uma escritura complexa de informao.

Roy Fielding (2000), em seu trabalho acadmico Architectural Styles and the
Design of Network-based Software Architectures, na Universidade da Califrnia, na sua
dissertao de doutorado estabelece os princpios orientadores para o que veio a ser
conhecido como REST, no houve muita movimentao da comunidade acadmica,
porem agora, muitos frameworks REST esto aparecendo e continuam sendo
desenvolvidos, devido a JSR-311 do Java 6.

3.3.1. Caractersticas

J as principais caractersticas da arquitetura REST so:

Pequenas quantidades de contedo textual formatado em XML OU JSON;

Na maioria dos casos opera sobre protocolo HTTP;

focado em expor recursos da aplicao de forma pblica, ou seja, por meio de

mtodos conhecidos;

No necessrio suporte especifico de linguagem, uma vez que, os dados so

transmitidos usando um XML simples ou uma string JSON;

Cdigo binrio no necessita ser transformado usando base64encod.

3.3.2. Situaes onde usar REST

Onde h limitao de recursos e de largura de banda;

Onde tem-se qualquer formato para o retorno e qualquer navegador pode ser
utilidao isso porque REST usa os padroes de chamada do HTTP, GET, PUT, POST,
DELETE e tambm pode utilizar os objetos XML, que so suportados pela grande
maioria de navegadores;
 Operaes totalmente sem-estado: se uma operao precisa ser continuada, o
REST no ser a melhor opo, no caso, se for necessario operaes de CRUD stateless
(Create, Read, Update and Delete),o REST seria a melhor alternativa;

Situaes que exigem cache: se a informao pode ser armazenada em cache

adequado para tecnologia.

4. Consideraes finais

Uma das vantagens do SOAP o uso de um mtodo de transporte genrico. Enquanto

que o REST faz uso de HTTP/HTTPS, o SOAP pode usar qualquer meio de transporte
existente para enviar suas requisies, deste SMTP (Simple Message, Transport,
Protocol) at mesmo JMS (Java Messaging Service). Contudo uma desvantagem
percebida no uso de XML a sua natureza trabalhosa e o tempo necessrio para analisar
o resultado apresentado. A Tecnologia REST, se sai bem em situaes em que h
limitao de recursos e de largura de banda, e em operaes que no precisa de estado,
j se uma operao precisa ser continuada a tecnologia SOAP a indicada.

Lembramos que a tecnologia SOAP, bastante madura e vem com uma

especificao definida pela W3C. Por tanto a melhor abordagem a flexibilidade, pois
no importa qual seja o problema, no mundo do desenvolvimento web, ao fazer uso
destes padres chega a resultados satisfatrios.

5. Referncias

Albinader Neto, et al. (2006), Web Services em Java, Rio de Janeiro, Brasport.

David A. Chappell and Tyler Jewell (2002), Java Web Services: Up and Running, O
Reilly Media; 1 edition

David A. Chappell and Tyler Jewell (2002), Java Web Services: Using java in Service-
Oriented Architectures, O Reilly Media; 1 edition

Introducing JSON (1999), disponvel em:<http://www.json.org>Acesso em 25/07/2014.

REST, Learn REST: A Tutorial, disponvel em: <http://rest.elkstein.org>Acesso em

15/08/2014.

Revista Devmedia, Entendendo os Padres de Descrio de Web Services (2013),

disponvel em:<http://www.devmedia.com.br> Acessado em 15/08/2014.

Revista Devmedia, Primeiros Passos com os servios REST (2013), disponvel

em:<http://www.devmedia.com.br> Acessado em 07/08/2014.

Web Services Architecture (2004), disponvel em:<http://www.w3.org/TR/wsdl/>

Acesso em 10/07/2014.