Isso provavelmente realmente pertence como comentários em várias das postagens acima, mas ainda não tenho o representante para fazer isso, então aqui vai.
Acho interessante que muitos dos prós e contras frequentemente citados para SOAP e REST têm (IMO) muito pouco a ver com os valores ou limites reais das duas tecnologias. Provavelmente, o pro mais citado para REST é que ele é "leve" ou tende a ser mais "legível por humanos". Em um nível, isso é certamente verdade, REST tem uma barreira menor de entrada - há menos estrutura necessária do que SOAP (embora eu concorde com aqueles que disseram que boas ferramentas são em grande parte a resposta aqui - uma pena que muitas das ferramentas SOAP são muito terrível).
Além desse custo de entrada inicial, entretanto, acho que a impressão REST vem de uma combinação da forma dos URLs de solicitação e a complexidade dos dados trocados pela maioria dos serviços REST. REST tende a encorajar URLs de solicitação mais simples e legíveis por humanos e os dados tendem a ser mais digeríveis também. Até que ponto, no entanto, são inerentes ao REST e até que ponto são meramente acidentais. A estrutura de URL mais simples é um resultado direto da arquitetura - mas poderia ser igualmente bem aplicada a serviços baseados em SOAP. Os dados mais digeríveis têm mais probabilidade de ser resultado da falta de qualquer estrutura definida. Isso significa que é melhor manter os formatos de dados simples ou você terá muito trabalho. Então, aqui está a estrutura adicional do SOAP,
Portanto, para uso na troca de dados estruturados entre sistemas de computador, não tenho certeza se REST é inerentemente melhor do que SOAP (ou vice-versa), eles são apenas diferentes. Acho que a comparação acima de REST x SOAP com tipagem dinâmica x estática é boa. Onde as linguagens dinâmicas tendem a ter problemas é na manutenção a longo prazo e manutenção de um sistema (e a longo prazo, não estou falando de um ano ou 2, estou falando de 5 ou 10). Será interessante ver se o REST enfrentará os mesmos desafios ao longo do tempo. Eu tendo a pensar que sim, se eu estivesse construindo um sistema de processamento de informações distribuído, eu gravitaria no SOAP como o mecanismo de comunicação (também por causa da transmissão e da camada de protocolo de aplicativo e flexibilidade que ele oferece, conforme mencionado acima).
Em outros lugares, embora REST pareça mais apropriado. AJAX entre o cliente e seu servidor (independentemente da carga útil) é um grande exemplo. Não me importo muito com a longevidade desse tipo de conexão e a facilidade de uso e flexibilidade são mínimas. Da mesma forma, se eu precisasse de acesso rápido a algum serviço externo e não achasse que me importaria com a manutenção da interação ao longo do tempo (novamente, estou assumindo que é aí que o REST vai acabar custando mais, de uma forma ou outro), então posso escolher REST apenas para poder entrar e sair rapidamente.
De qualquer forma, ambas são tecnologias viáveis e, dependendo de quais compensações você deseja fazer para um determinado aplicativo, elas podem atendê-lo bem (ou mal).