Quem tenha lidado com webservices nos últimos tempos, ou se deparou com o debate SOAP vs REST, ou andou com a cabeça enfiada na areia. Para quem andou com a cabeça enfiada na areia, aqui vai um resumo pragmático:

• Um webservice é uma maneira de uma aplicação comunicar com um servidor Web. Tradicionalmente, quem interage com um servidor web é um ser humano, através de um browser. Se trocarmos o ser humano por uma aplicação, a interacção passa a ser por webservices.
• Podem-se implementar webservices de várias maneiras. Duas delas ganharam notoriedade, por diferentes razões: SOAP e REST
• SOAP é pegar numa mensagem xml, metê-la num envelope e enviá-la 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.
• 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.

Feito o resumo, vamos directos para as conclusões:

• 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. Digo isto, porque ninguém no seu perfeito juízo implementa a comunicação SOAP à mão. 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 (muitas delas pagas, está claro). 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. Desde que não se tenha que olhar para o código gerado, está tudo bem. Mas a law of leaky abstractions diz-nos que mais cedo ou mais tarde vamos ter que olhar para o código. E nessa altura, vamos chamar bastantes nomes ao SOAP e aos seus geradores de código.
• 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 é exactamente igual. Se fôr em SOAP, practicamente 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 objectos. 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.
• Dito isto, por vezes 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. Nesse caso, sugiro uma ferramenta do tipo do enunciate que, pelo menos, garante que sem esforço adicional temos webservices para todos os gostos (UPDATE 2018: o enunciate já não existe e tanto quanto sei não há ferramentas que providenciem com pouco esforço as duas opções).