O documento compara as arquiteturas SOAP e REST para serviços web. SOAP usa mensagens XML em envelopes HTTP, enquanto REST usa métodos HTTP como GET e POST para transmitir dados XML ou outros formatos. REST é mais leve e compatível com a web, mas SOAP tem mais ferramentas e padrões. Ambos têm pontos positivos e negativos dependendo do projeto.

1. CENTRO UNIVERSITÁRIO DO TRIÂNGULO
INSTITUTO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE CIÊNCIA DA COMPUTAÇÃO
Trabalho PSDC
Alunos: Plínio Ferreira da Silva
Professor: Vinícius de Paula
Uberlândia, 23 de junho de 2014.

2. 2
Sumário
Diferenças conceituais e arquiteturais existentes entre a utilização do SOAP e do REST..................3
Pontos positivos e negativos...............................................................................................................5

3. 3
Diferenças conceituais e arquiteturais existentes entre a utilização do SOAP
e do REST
O SOAP e o REST são duas alternativas para fazer uma aplicação comunicar com um
servidor Web.
Nos padrões WS-*, as mensagens trocadas entre serviço e cliente consumidor devem ser
armazenadas em envelopes SOAP. Este protocolo de comunicação dita um formato de envio
de mensagens entre aplicações, o qual é descentralizado e distribuído, ou seja, qualquer
plataforma de comunicação pode ser utilizada, seja ela proprietária ou não.
SOAP utiliza uma mensagem xml, coloca em um envelope e envia por HTTP (embora o
SOAP permita diferentes protocolos de transporte, na prática é HTTP). A resposta vem
igualmente num envelope, em xml. Apesar de utilizar HTTP, esqueçam quaisquer
mecanismos pré-existentes na linguagem/framework para comunicar em SOAP. Aquilo
utiliza uns headers especiais, como tal precisam de uma biblioteca especializada.
Mensagem SOAP
REST é usar o HTTP como ele foi concebido, com GET, POST, PUT e DELETE (estes
últimos dois quase não são utilizados mas estão na especificação desde o início). Ou seja, se
sabem fazer submit de forms, sabem usar REST. A diferença é que o submit de um form
devolve uma página em html, e um webservice REST devolve uma página em xml. O termo é
geralmente usado para descrever qualquer interface que transmita dados de um domínio
específico sobre HTTP sem uma camada adicional de mensagem como SOAP ou session
tracking via cookies HTTP. Estes dois conceitos podem entrar tanto em conflito como em
sobreposição.
É possível desenvolver um sistema de software de acordo com as restrições impostas pelo
estilo arquitetural REST sem usar HTTP e sem interagir com a Web. Também se torna
possível projetar interfaces HTTP + XML que não condizem com os princípios REST de

4. 4
Fielding. Sistemas que seguem os princípios REST são referenciados também como
“RESTful”.
O SOAP não foi desenhado para resolver um problema, mas sim para vender ferramentas, ou
não estivessem big players como a Microsoft ou a Oracle envolvidos. Pois não se implementa
a comunicação SOAP manualmente. Quem definiu o standard, garantiu que o formato era
suficientemente críptico e complexo para ser utilizável apenas recorrendo a
bibliotecas/ferramentas de terceiros. Teoricamente a ideia é boa. Pego num WSDL (que é a
definição do webservice em XML) e gero uma molhada de código que sabe tratar aquilo.
Um padrão recorrente em aplicações Web é a disponibilização da mesma funcionalidade via
HTML e via Webservice. Se o WebService fôr REST podemos reutilizar tudo menos a
apresentação, que no primeiro caso é em HTML e no segundo em XML. Isto porque o
request HTTP é exatamente igual. Se fôr em SOAP, praticamente temos que refazer/duplicar
a componente servidor.
Se pensarmos em aplicações Web de grande escala, o SOAP é a morte do artista. Primeiro
porque as ferramentas insistem que se carregue sempre toda a mensagem para memória num
DOM de objetos. Não podemos ir processando incrementalmente (streaming), tem que ir tudo
para memória. Em REST, fazer streaming é limpinho: é só obter um InputStream para a
HttpConnection (em Java, noutras linguagens há-de ser semelhante) e ir consumindo ao ritmo
que entendermos. Por outro lado, juntando o peso de envelopar/desenvelopar as mensagens
SOAP ao facto de os mecanismos de caching na Web não se aplicarem, temos um caso
bicudo se planearmos receber mais do algumas dezenas de pedidos Webservice por minuto.
Neste caso temos necessidade de implementar webservices em SOAP, seja por que o cliente
comprou a ferramenta X, ou porque as aplicações clientes querem usar SOAP, etc. Por isso,
seria melhor uma ferramenta do tipo do enunciate que garante que sem esforço adicional
temos webservices para todos os gostos.

5. 5
Pontos positivos e negativos
REST
Pontos Positivos Pontos Negativos
 Linguagem e plataforma agnóstica.
 Simplicidade, interface imutável.
 Interação assíncrona, não possui
estado.
 Facilidade de adoção, pois não
requer uma grande infraestrutura,
muito menos um middleware para
WS-* ou camada intermediária
adicional.
 Utiliza a própria web como meio de
transporte, sendo assim uma carga
baixa para a rede.
 Utilizada por grande parte das
aplicações Web 2.0. (Google, Flickr,
Amazon, etc..). Portanto, ótimo para
mashups.
 Curva de aprendizagem baixa.
 Faltam padrões.
 Falta de segurança (dados sigilosos não
deveriam ser enviados como parâmetros na
URI).
 Não é indicado para trafegar grandes
volumes de parâmetros via URI, no caso de
PUT/POST para inclusão de dados, por
exemplo.
 Em muitas empresas apenas os métodos
GET e POST do HTTP são liberados em
proxies e firewalls. Dentro desta limitação,
muitos preferem utilizar os métodos GET
para requisições de consulta e POST para
todo o resto.
 Não há mecanismos de transação (Do it
yourself)
 Não existe um padrão como UDDI para
service discovery.
SOAP
Pontos Positivos Pontos Negativos
 Diversas ferramentas de
desenvolvimento.
 Tipagem forte e um vocabulário bem
definido.
 Quando utilizado sobre HTTP,
dificilmente é bloqueado por proxies e
firewalls.
 Permite o uso de diferentes tipos de
protocolos.
 Plataforma independente.
 Linguagem independente.
 Diversos padrões.
 Complexidade dos padrões.
 Performance.
 Mensagens podem ficar muito extensas,
por serem codificadas com XML