You are on page 1of 4

stackoverflow.

com

Otimizado h 22 horas
Ver original Atualizar
Leia este post no nosso aplicativo!

Diferenas de tipos de Web Service: SOAP, REST, XML


65

web-service

Quais as principais diferenas entre esses tipos de Web Service?


Em quais casos se aplicam?
Existe alguma diferena de performance?
compartilhar

melhorar esta pergunta

perguntada
31/03/14 s 20:15

Laerte
9.8453 40 99

editada
8/11/15 s 3:38

2 Respostas ordenar por votos


71

SOAP
SOAP um protocolo de transferncia de mensagens em formato XML para uso em ambientes
distribudos. O padro SOAP funciona como um tipo de framework que permite a interoperabilidade
entre diversas plataformas com mensagens personalizadas.
Aplicando este padro em Web Services, geralmente usa-se o WSDL para descrever a estrutura das
mensagens SOAP e as aes possveis em um endpoint.
Uma das maiores vantagens disso que vrias linguagens e ferramentas conseguem ler e gerar
mensagens facilmente. Vrias linguagens de programao permitem a gerao de objetos de domnio,
Stubs e Skeletons a partir da denio do WSDL, permitindo a comunicao remota via RPC atravs de
chamadas a mtodos remotos, inclusive com argumentos complexos, como se fossem chamadas
locais.
O problema desse padro, que ele adiciona um overhead considervel, tanto por ser em XML quanto
por adicionar muitas tags de meta-informao. Alm disso, a serializao e desserializao das
mensagens pode consumir um tempo considervel.

REST
REST outro um protocolo de comunicao, baseado no protocolo de hipermdia HTTP. Porm ele no
impe restries ao formato da mensagem, apenas no comportamento dos componentes envolvidos.
A maior vantagem do protocolo REST sua flexibilidade. O desenvolvedor pode optar pelo formato
mais adequado para as mensagens do sistema de acordo com sua necessidade especca. Os
formatos mais comuns so JSON, XML e texto puro, mas em teoria qualquer formato pode ser usado.
Isso nos leva a outra vantagem: quase sempre Web Services que usam REST so mais "leves" e,
portanto, mais rpidos.

O problema com o REST pode surgir justamente por causa de suas vantagens. Como a denio do
corpo de dados ca totalmente a cargo do desenvolvedor, os problemas de interoperabilidade so mais
comuns.

SOAP ou REST?
Aviso: Esta uma opinio pragmtica.
Em geral, SOAP uma boa opo para instituies com padres rgidos e ambientes complexos (vrias
plataformas e sistemas). Muitas ferramentas corporativas (como ESB) tiram vantagem do padro e
possibilitam ltrarem, enleiramento, classicao e redirecionamento das mensagens trocadas entre
sistemas.
No restante, para uso no dia-a-dia, no vejo motivos concretos para no usar REST e JSON.
Praticamente todas as plataformas e linguagens modernas que conheo suportam esses conceitos e a
soluo nal muito mais simples do que o equivalente em SOAP.
Alm disso, integraes com alto volume de requisies so inviveis em SOAP. REST capaz de
atender volume e complexidade sem diculdades, exigindo apenas um mnimo de experincia do
desenvolvedor para estabelecer e reforar os padres adequados.

compartilhar

melhorar esta resposta

respondida
31/03/14 s 20:48

utluiz
49,4mil5 77 176

editada
3/02 s 14:23

Laerte
9.8453 40 99

O uso dos mtodos padres HTTP 1.1 (get, post, put e delete...) pode ser considerado uma vantagem em REST? Ricardo
Giaviti 1/04/14 s 1:42

@RicardoGiaviti No me parece uma vantagem, est mais para uma caracterstica ou restrio. SOAP tambm funciona
sobre HTTP, embora isso seja encoberto pelas camadas do protocolo. utluiz 1/04/14 s 2:09

@RicardoGiaviti Na verdade, pensando melhor, o fato de REST usar s HTTP faz com que ele seja mais simples, leve,
eciente e compatvel do que o SOAP, que exige mais camadas de complexidade. Porm, quanto a usar os mtodos
padro do HTTP, isso me parece mais uma caracterstica. Seria como armar que um carro melhor que uma moto
porque tem 4 rodas. utluiz 1/04/14 s 11:53

Eu sempre tive essa dvida, porm acho que isso levemente uma vantagem pois no foi preciso "reinventar a roda" com
novas especicaes de protocolos, por exemplo. J utilizado "pronto" e ainda mantido por uma organizao sria.
Ricardo Giaviti 1/04/14 s 12:35
comentar

27

XML um tipo de documento, no um tipo de WebService, e ele usado pelo mtodo SOAP para
troca de mensagens.
O texto a seguir foi retirado de: http://www.infoq.com/br/articles/rest-soap-when-to-use-each
O REST faz uso de um padro de URI (Uniform Resource Identier), fazendo uma chamada para um
servio web como em: http://www.minhaempresa.com.br/programa/metodo?Parametros=xx

O REST simples de entender e pode ser adotado em praticamente qualquer cliente ou servidor com
suporte a HTTP/HTTPS. Os desenvolvedores que o utilizam citam, como principais vantagens a
facilidade no desenvolvimento, o aproveitamento da infraestrutura web existente e um esforo de
aprendizado pequeno.
Por outro lado, o SOAP, av das interfaces de servios web, no deixar de ser usado to cedo. Com o
SOAP v 1.2, muitas das decincias percebidas nessa tecnologia foram corrigidas e aumentou a
facilidade de uso. Alm disso, a sigla SOAP deixou de representar "Simple Object Access Protocol". Na
especicao 1.2 da W3C, SOAP apenas o nome da especicao.
Utilizar o SOAP 1.2 traz uma carga adicional no encontrada ao usar REST, mas h tambm
vantagens. Primeiramente o SOAP baseado em XML, de trs formas: o envelope, que dene o
contedo da mensagem e informa como process-la; um conjunto de regras de codicao para os
tipos de dados; e o layout para os procedimentos de chamadas e respostas. Esse "envelope" enviado
por meio de (por exemplo) HTTP/HTTPS. E uma RPC (Remote Procedure Call) executada, e o
envelope retorna com as informaes do documento XML formatado.
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 sua
requisio, desde SMTP at mesmo JMS (Java Messaging Service). No entanto, uma desvantagem
percebida no uso de XML a sua natureza prolixa e o tempo necessrio para analisar o resultado
apresentado.
Mas uma histria no contada que ambas as tecnologias podem ser misturadas e combinadas. O
REST fcil de entender e extremamente acessvel porm faltam padres, e a tecnologia
considerada apenas uma abordagem arquitetural. Em comparao, o SOAP um padro da indstria,
com protocolos bem denidos e um conjunto de regras bem estabelecidas.
Pode-se armar, ento, que casos onde o REST funciona bem so:
Situaes em que h limitao de recursos e de largura de banda: A estrutura de retorno em
qualquer formato denido pelo desenvolvedor e qualquer navegador pode ser usado. Isso porque a
abordagem REST usa o padro de chamadas GET, PUT, POST e DELETE. O REST tambm pode usar
objetos XMLHttpRequest (a base do velho AJAX) que a maioria dos navegadores modernos
suporta.
Operaes totalmente sem-estado: se uma operao precisa ser continuada, o REST no ser a
melhor opo. No entanto, se forem necessrias operaes de CRUD stateless (Criar, Ler, Atualizar
e Excluir), o REST seria a melhor alternativa.
Situaes que exigem cache: se a informao pode ser armazenada em cache, devido natureza
da operao stateless do REST, esse seria um cenrio adequado para a tecnologia.
Essas trs situaes abrangem muitas solues. Ento por que ainda precisamos considerar o uso do
SOAP? Mais uma vez, o SOAP bastante maduro e bem denido e vem com uma especicao
completa. J a abordagem REST apenas isso: uma abordagem. Est totalmente aberta. Por isso ao
se encontrar uma das situaes abaixo, o SOAP pode ser uma tima soluo:
Processamento e chamada assncronos: se o aplicativo precisa de um nvel garantido de
conabilidade e segurana para a troca de mensagens, ento o SOAP 1.2 oferece padres
adicionais para esse tipo de operao como por exemplo o WSRM (WS-Reliable Messaging).
Contratos formais: se ambos os lados (fornecedor e consumidor) tm que concordar com o
formato de intercmbio de dados, ento o SOAP 1.2 fornece especicaes rgidas para esse tipo
de interao.
Operaes stateful: para o caso de o aplicativo precisar de informao contextual e gerenciamento
de estado com coordenao e segurana, o SOAP 1.2 possui uma especicao adicional em sua
estrutura que apoia essa necessidade (segurana, transaes, coordenao etc.).

Comparativamente, usar o REST exigiria que os desenvolvedores construssem uma soluo


personalizada.
Como se v, cada uma das abordagens tem sua utilidade. Ambas tm problemas nos quesitos de
segurana, camadas de transporte etc.; mas ambas podem realizar o trabalho necessrio e trazem sua
contribuio para o desenvolvimento de aplicaes web.
Retirado de: http://www.infoq.com/br/articles/rest-soap-when-to-use-each

compartilhar

melhorar esta resposta

respondida
31/03/14 s 20:52
user3628

editada
31/03/14 s 21:06

meta chat tour ajuda blog poltica de privacidade legal entre em contato conosco site completo
2016 Stack Exchange, Inc

You might also like