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

从“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而不是SOAP。我只能假设这些人不是开发人员，或者从未真正实现过任何合理规模的REST服务。实现REST服务比实现SOAP服务花费的时间要长得多。最后，它也变得更加混乱。以下是我在99%的情况下选择SOAP的原因:

1)实现REST服务比实现SOAP服务花费无限长的时间。存在用于所有现代语言/框架/平台读取WSDL并输出代理类和客户机的工具。实现REST服务是手工完成的，并且—通过阅读文档来实现。此外，在实现这两个服务时，由于没有真正的模式或引用文档，您必须“猜测”哪些内容将通过管道返回。

2)为什么要编写一个返回XML的REST服务?唯一不同的是，使用REST时，你不知道每个元素/属性代表的类型——你只能自己实现它，并希望有一天在你认为总是int的字段中不会遇到字符串。SOAP使用WSDL定义数据结构，因此这很简单。

3)我听到过这样的抱怨:使用SOAP，你有SOAP信封的“开销”。在这个时代，我们真的需要担心几个字节吗?

4)我听说过这样一种说法:使用REST，你只需将URL弹出到浏览器中，就可以看到数据。当然，如果您的REST服务使用简单身份验证或不使用身份验证。例如，Netflix的服务使用OAuth，它要求你在提交请求之前签名和编码。

5)为什么我们需要一个“可读”的URL为每个资源?如果我们使用工具来实现服务，我们真的关心实际的URL吗?

还需要我继续说下去吗?

这是微妙的。

如果您需要让其他系统与您的服务进行接口，那么由于您使用契约、WSDL和SOAP标准所拥有的“验证”层，许多客户端将更乐于使用SOAP。

对于日常系统对系统的调用，我认为SOAP是很多不必要的开销，而简单的HTML调用就可以了。

当我在惠普工作时，我根据开发中的原始规范构建了第一批SOAP服务器之一，包括代码生成和WSDL生成。我不建议在任何事情上使用SOAP。

首字母缩写“SOAP”是一个谎言。它不是简单的，它不是面向对象的，它没有定义访问规则。可以说，它是一项议定书。这是Don Box有史以来最糟糕的规格，这是一个相当了不起的壮举，因为他是“COM”的创造者。

SOAP中没有什么有用的东西是REST不能用于传输的，JSON、XML甚至纯文本不能用于数据表示的。为了传输安全，可以使用https协议。对于认证，使用基本认证。对于会话，有cookie。REST版本将更简单、更清晰、运行更快、使用更少的带宽。

XML-RPC清楚地定义了请求、响应和错误协议，并且对于大多数语言都有很好的库。但是，对于许多任务来说，XML比您所需要的要重。

快速了解一下2012年的问题:

REST在以下方面发挥了很好的作用:

Limited bandwidth and resources. Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX. Totally stateless operations. If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it. Caching situations. If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.That covers a lot of solutions in the above three.

那么我为什么要考虑SOAP呢?同样，SOAP是相当成熟和定义良好的，并且带有完整的规范。REST方法就是这样一种方法，它对开发非常开放，所以如果你具备以下条件，那么SOAP就是一个很好的解决方案:

Asynchronous processing and invocation. If your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging. Formal contracts. If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction. Stateful operations. If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.

http://www.infoq.com/articles/rest-soap-when-to-use-each