Respondendo à pergunta atualizada de 2012 (pela segunda recompensa) e revisando os resultados de hoje (outras respostas).
SOAP, prós e contras
Sobre o SOAP 1.2, vantagens e desvantagens ao comparar com "REST" ... Bem, desde 2007,
você pode descrever os serviços da Web REST com WSDL e usar o protocolo SOAP ... Ou seja, se você trabalhar um pouco mais, todos os padrões W3C de a pilha de protocolos de serviços da web pode ser REST !
É um bom ponto de partida, porque podemos imaginar um cenário em que todas as discussões filosóficas e metodológicas são temporariamente evitadas. Podemos comparar tecnicamente "SOAP-REST" com "NON-SOAP-REST" em serviços semelhantes,
SOAP-REST (= "REST-SOAP"): conforme mostrado por L.Mandel , o WSDL2 pode descrever um serviço da web REST e, se supusermos que XML exemplificado possa ser envolvido em SOAP, toda a implementação será "SOAP-REST" .
NÃO SOAP-REST : qualquer serviço da Web REST que não possa ser SOAP ... Ou seja, "90%" dos exemplos REST conhecidos. Alguns não usam XML (por exemplo, RESTs AJAX típicos usam JSON), outros usam outras estruturas XML, sem os cabeçalhos ou regras SOAP. PS: para evitar a informalidade, podemos supor o nível 2 do REST nas comparações.
Obviamente, para comparar de maneira mais conceitual, compare "NON-REST-SOAP" com "NON-SOAP-REST", conforme abordagens de modelagem diferentes. Portanto, concluindo esta taxonomia de serviços da web:
NÃO REST-SOAP : qualquer serviço da web SOAP que não possa ser REST ... Ou seja, "90%" dos exemplos SOAP conhecidos.
NÃO REST-SOAP-SOAP : sim, o universo da "modelagem de serviços da web" compreende outras coisas (por exemplo, XML-RPC ).
SOAP nas condições REST
Comparando coisas comparáveis: SOAP-REST com NON-SOAP-REST .
PROS
Explicando alguns termos,
Estabilidade contratual : para todos os tipos de contratos (como "acordos escritos"),
Pelo uso de padrões : todos os níveis da pilha W3C são mutuamente compatíveis. O REST, por outro lado, não é um padrão W3C ou ISO e não possui detalhes normatizados sobre os periféricos do serviço. Então, como eu , @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0) disse antes, em um contexto em que NECESSITAM DE NORMAS, você precisa de SOAP.
Pelo uso das melhores práticas : o "aspecto detalhado" das implementações da pilha do W3C traduz os acordos humanos / legais / jurídicos relevantes.
Robustez : a segurança da estrutura e cabeçalhos do SOAP. Com a comunicação metada (com toda a expressividade do XML) e a verificação, você tem uma "apólice de seguro" contra alterações ou ruídos.
O SOAP tem "confiabilidade transacional (...) que lida com falhas de comunicação. O SOAP tem mais controles em torno da lógica de repetição e, portanto, pode fornecer mais confiabilidade de ponta a ponta e garantias de serviço", E. Terman .
Classificando profissionais por popularidade,
Melhores ferramentas (~ 70 votos): o SOAP atualmente tem a vantagem de melhores ferramentas, desde 2007 e ainda 2012, porque é um padrão bem definido e amplamente aceito. Veja @MarkCidade (27 votos), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).
Conformidade com os padrões (25 votos): como eu disse @DaveWoldrich (20 votos), @cynicalman (5), @Exitos (0) antes, em um contexto em que NECESSITAMOS DE NORMAS, você precisa de SOAP.
Robustez : seguro de cabeçalhos SOAP, @JohnSaunders (8 votos).
CONS
A estrutura SOAP é mais complexa (mais de 300 votos): todas as respostas aqui e fontes sobre "SOAP vs REST" manifestam algum grau de aversão à redundância e complexidade do SOAP. Essa é uma consequência natural dos requisitos de verificação formal (veja abaixo) e de robustez (veja acima). "REST NÃO SOAP" (e XML-RPC, o originador SOAP ) pode ser mais simples e informal.
A restrição "only XML" é um obstáculo ao desempenho ao usar serviços minúsculos (~ 50 votos): consulte json.org/xml e esta questão ou esta . Este ponto é mostrado por @toluju (41) e outros.
PS: como JSON não é um padrão IETF , mas podemos considerar um padrão de fato para a comunidade de software da web.
Serviços de modelagem com SOAP
Agora, podemos adicionar comparações SOAP-NON-REST com NON-SOAP-REST e explicar quando é melhor usar o SOAP :
Necessidade de padrões e contratos estáveis (consulte a seção "PROS"). PS: consulte uma "necessidade B2B de padrões" descrita por @saille .
Necessidade de ferramentas (consulte a seção "PROS"). PS: os padrões e a existência de verificações formais (veja abaixo) são questões importantes para a automação das ferramentas.
Processamento pesado paralelo (consulte a seção "Contexto / Fundações" abaixo): com processos maiores e / ou mais lentos, não importa com um pouco mais de complexidade do SOAP, confiabilidade e estabilidade são os melhores investimentos.
Precisa de mais segurança : quando é necessário mais do que HTTPS e você realmente precisa de recursos adicionais para proteção, o SOAP é uma escolha melhor ( consulte @Bell , 32 votos). "Enviar a mensagem por um caminho mais complicado que solicitação / resposta ou por um transporte que não envolve HTTP", S. Seely . XML é um problema central, oferecendo padrões para criptografia XML , assinatura XML e canonização XML e, somente com SOAP é possível incorporar esses mecanismos a uma mensagem de acordo com um padrão bem aceito como WS-Security .
Precisa de mais flexibilidade (menos restrições): o SOAP não precisa de correspondência exata com um URI; não restrito a HTTP; não precisa restringir a 4 verbos. Como o @TravisHeseman (9 votos) diz, se você quiser algo "flexível para um número arbitrário de tecnologias e usos de clientes", use SOAP.
PS: lembre-se de que XML é mais universal / expressivo que JSON (et al).
Necessidade de verificações formais : importante entender que a pilha W3C usa métodos formais e o REST é mais informal. Sua descrição de serviço WSDL (uma linguagem formal ) é uma especificação formal de suas interfaces de serviços da web e SOAP é um protocolo robusto que aceita todas as prescrições possíveis de WSDL.
CONTEXTO
Histórico
Para avaliar tendências é necessária perspectiva histórica. Para este assunto, uma perspectiva de 10 ou 15 anos ...
Antes da padronização do W3C, havia alguma anarquia. Foi difícil implementar serviços interoperáveis com estruturas diferentes e mais difícil, caro e demorado para implementar algo interoperável entre as empresas. Os padrões de pilha W3C têm sido uma luz, um norte para a interoperação de conjuntos de serviços web complexos.
Para tarefas do dia-a-dia, como implementar AJAX, o SOAP é pesado ... Portanto, a necessidade de abordagens simples precisa eleger uma nova estrutura teórica ... E grandes "players de software da Web", como Google, Amazon, Yahoo et al. Elegeram a melhor alternativa, que é a abordagem REST. Foi nesse contexto que o conceito REST chegou como uma "estrutura competitiva" e, hoje (2012), essa alternativa é de fato um padrão para programadores.
Fundações
Em um contexto de computação paralela, os serviços da web fornecem subtarefas paralelas; e protocolos, como SOAP, garantem boa sincronização e comunicação. Não é "nenhuma tarefa": os serviços da Web podem ser classificados como
paralelismo de granulação grossa e embaraçoso .
À medida que a tarefa aumenta, torna-se menos significativo "debate da complexidade" e torna-se mais relevante a robustez da comunicação e a solidez dos contratos.