我建议您先使用REST——如果您正在使用Java，请查看JAX-RS和Jersey实现。REST更简单，易于在多种语言中进行互操作。

正如其他人在这篇文章中所说，SOAP的问题在于当其他WS-*规范加入时它的复杂性，如果您误入WSDL、xsd、SOAP、WS- addressing等的错误部分，就会出现无数的互操作问题。

判断REST和SOAP之争的最好方法是看看互联网——几乎所有网络领域的大玩家，谷歌、amazon、ebay、twitter等——都倾向于使用并偏爱RESTful api而不是SOAP api。

使用REST的另一个很好的方法是，你可以在web应用程序和REST前端之间重用大量的代码和基础设施。例如，使用JAX-RS和隐式视图等框架，将资源的HTML、XML和JSON呈现出来通常是非常容易的，而且使用web浏览器也很容易处理RESTful资源

我创建了一个基准，以找出它们中哪一个更快! 我看到了这样的结果:

对于1000个请求:

休息用时3秒 SOAP耗时7秒

对于10,000个请求:

休息用时33秒 SOAP用时69秒

对于1,000,000个请求:

休息用时62秒 SOAP耗时114秒

SOAP体现了Web服务的面向服务的方法——在这种方法中，方法(或动词)是与服务交互的主要方式。REST采用面向资源的方法，其中对象(或名词)占据中心位置。

从工具的角度来看，SOAP很有用，因为工具很容易使用WSDL。因此，您可以用您喜欢的语言为您生成Web服务客户机。

REST在AJAX的网页上表现得很好。如果保持请求的简单性，就可以直接从JavaScript调用服务，这非常方便。尽量避免在响应XML中使用任何名称空间，我看到浏览器在使用这些名称空间时会窒息。因此，xsi:type可能不适合您，没有过于复杂的XML schema。

REST tends to have better performance as well. CPU requirements of the code generating REST responses tend to be lower than what SOAP frameworks exhibit. And, if you have your XML generation ducks lined up on the server side, you can effectively stream XML out to the client. So, imagine you're reading rows of database cursor. As you read a row, you format it as an XML element, and you write that directly out to the service consumer. This way, you don't have to collect all of the database rows in memory before starting to write your XML output - you read and write at the same time. Look into novel templating engines or XSLT to get the streaming to work for REST.

另一方面，SOAP往往是由工具生成的服务生成的一个大blob，然后才编写。请注意，这并不是绝对的事实，有很多方法可以从SOAP中获得流特性，比如使用附件。

我的决策过程如下:如果我想让我的服务易于被消费者使用，并且我编写的消息将是中等到小型的(10MB或更小)，并且我不介意在服务器上消耗一些额外的CPU周期，那么我就使用SOAP。如果我需要在web浏览器上使用AJAX，或者我需要进行流式处理，或者我的响应非常大，我就使用REST。

最后，围绕SOAP建立了许多很棒的标准，如WS-Security和获得有状态的Web服务，如果使用正确的工具，可以将它们插入。这类东西真的很重要，可以帮助您满足一些棘手的要求。

从“PHP-宇宙”的意义上讲，PHP对任何高级SOAP的支持都很糟糕。一旦您满足了基本需求，您最终将使用类似http://wso2.com/products/web-services-framework/php/的东西，甚至启用没有内置支持的WS-Security或WS-RM。

我觉得在PHP中创建SOAP信封是非常混乱的，它创建命名空间的方式，xsd:nil, xsd:anytype和老式的SOAP服务使用SOAP编码(上帝知道这有什么不同)与SOAP消息。

通过坚持REST来避免所有这些混乱，REST并不是什么大不了的东西，我们从WWW开始就在使用它。直到这篇http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm论文发表后，我们才意识到，它展示了如何使用HTTP功能来实现RESTFul服务。HTTP本质上是REST，这并不意味着仅仅使用HTTP就可以使您的服务RESTFul。

SOAP忽略了HTTP的核心功能，只将HTTP视为传输协议，因此理论上它是独立于传输协议的(实际上并非如此，您听说过SOAP Action报头吗?如果不是现在!)。

随着JSON适应的增加以及HTML5和javascript的成熟，REST和JSON已经成为处理服务的最常见方式。JSON Schema也被定义为可以在需要时与WADL一起用于企业级解决方案(仍处于早期阶段)。

PHP对REST和JSON的支持肯定比现有的内置SOAP支持更好。

在这里添加更多的术语SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

顺便说一下，我非常喜欢SOAP，特别是WS-Security规范，这是一个很好的规范，如果有人在考虑企业JSON适应肯定需要一些类似JSON的东西，比如字段级加密等。

我也在关注同样的问题。在我看来，REST实际上是快速和简单的，适用于轻量级调用和响应，并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。

然而，REST的不足之处在于它不是一个标准(尽管它由标准组成)。大多数编程库都有一种检查WSDL以自动生成消费基于SOAP的服务所需的客户端代码的方法。到目前为止，使用基于REST的web服务似乎是一种更特别的方法，即编写接口来匹配可能的调用。手动发起http请求，然后解析响应。这本身就是危险的。

SOAP的美妙之处在于，一旦WSDL被发布，那么业务就可以构造它们的逻辑主干，从而设置契约，对接口的任何更改都会改变WSDL。没有任何回旋的余地。您可以根据该WSDL验证所有请求。然而，由于WSDL没有正确地描述REST服务，因此您没有定义的方式来就通信的接口达成一致。

从商业的角度来看，这似乎让沟通变得容易解释和改变，这似乎是个坏主意。

这个线程中最上面的“答案”似乎说SOAP代表简单面向对象访问协议，然而在wiki中，O意味着对象不是面向对象的。它们是不同的东西。

我知道这篇文章很老了，但我认为我应该用我自己的发现来回应。