从“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应用程序中发送SOAP信封。

SOAP本身实际上是相当基本和简单的，它之上的WSS-*标准使它非常复杂。

如果您的消费者是其他应用程序和其他服务器，那么目前对SOAP协议有很多支持，在现代ide中移动数据的基本操作基本上就是单击鼠标。

如果您的消费者更有可能是ria或Ajax客户端，那么您可能希望使用比SOAP更简单、更适合客户端的东西(特别是JSON)。

通过HTTP发送的JSON包不一定是REST体系结构，它只是发送到url的消息。所有这些都是完全可行的，但是REST习惯用法有一些关键组件。然而，这两者很容易混淆。但是，仅仅因为您谈论的是HTTP请求，并不一定意味着您拥有REST体系结构。您可以有一个完全没有HTTP的REST应用程序(注意，这种情况很少见)。

因此，如果您的服务器和消费者对SOAP“满意”，SOAP和WSS堆栈就可以很好地为您服务。如果你在做一些特别的事情，想要更好地与web浏览器交互，那么一些轻量级的HTTP协议也可以很好地工作。

从工具的角度来看，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服务，如果使用正确的工具，可以将它们插入。这类东西真的很重要，可以帮助您满足一些棘手的要求。

请收听本期播客找出答案。如果你想在不听的情况下知道答案，那么好吧，这是REST。但我真的建议你听。

我相信Don Box创建SOAP是一个笑话——“看，你可以在web上调用RPC方法”，今天当他意识到它已经成为一个臃肿的web标准的噩梦时，他会呻吟:-)

REST很好，很简单，在任何地方都可以实现(所以它更像是一个“标准”，而不是标准)，又快又简单。使用REST。

我的一般规则是，如果你想要一个浏览器web客户端直接连接到一个服务，那么你可能应该使用REST。如果希望在后端服务之间传递结构化数据，则使用SOAP。

SOAP的设置有时真的很痛苦，对于简单的web客户端和服务器数据交换来说，它通常是多余的。不幸的是，我所见过(并从中学到)的大多数简单编程示例都在某种程度上强化了这种看法。

That said, SOAP really shines when you start combining multiple SOAP services together as part of a larger process driven by a data workflow (think enterprise software). This is something that many of the SOAP programming examples fail to convey because a simple SOAP operation to do something, like fetch the price of a stock, is generally overcomplicated for what it does by itself unless it is presented in the context of providing a machine readable API detailing specific functions with set data formats for inputs and outputs that is, in turn, scripted by a larger process.

在某种程度上，这是可悲的，因为它确实给SOAP带来了坏名声，因为如果不在最终产品如何使用的完整上下文中展示它，就很难展示SOAP的优点。