一个快速点传输协议和编制;

出于速度、可靠性和安全性的考虑，我在TCP上使用SOAP，包括编排的机器对机器服务(ESB)和外部服务。更改服务定义，业务流程会从WSDL更改中引发一个错误，并且它会立即显现出来，并且可以重新构建/部署。

不确定你可以用REST做同样的事情-我等待被纠正或课程! 使用REST，更改服务定义—在返回400(或其他值)之前，没有人知道它。

REST是一种与SOAP完全不同的范例。关于REST的一篇好文章可以在这里找到:我如何向我的妻子解释REST。

如果你没有时间阅读它，这里是一个简短的版本:REST是一个范式的转变，通过关注“名词”，并限制你可以应用于这些名词的“动词”的数量。唯一允许使用的动词是“get”、“put”、“post”和“delete”。这与SOAP不同，SOAP中许多不同的动词可以应用于许多不同的名词(即许多不同的功能)。

对于REST，四个动词映射到相应的HTTP请求，而名词则由url标识。这使得状态管理比SOAP更加透明，在SOAP中，服务器上的状态和客户端上的状态往往不清楚。

但在实践中，大多数情况下，REST通常只是指以JSON返回结果的简单HTTP请求，而SOAP是一种更复杂的API，通过传递XML进行通信。两者都有各自的优点和缺点，但是根据我的经验，我发现REST通常是更好的选择，因为您很少需要从SOAP获得的全部功能。

SOAP目前具有更好的工具的优势，它们可以为服务层生成大量样板代码，也可以从任何给定的WSDL生成客户端。

REST更简单，因此更容易维护，位于Web体系结构的核心，允许更好的协议可见性，并且已被证明可以扩展到WWW本身的大小。有些框架可以帮助您构建REST服务，如Ruby on Rails，有些甚至可以帮助您编写客户端，如ADO。NET数据服务。但在大多数情况下，缺乏工具支持。

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

对于1000个请求:

休息用时3秒 SOAP耗时7秒

对于10,000个请求:

休息用时33秒 SOAP用时69秒

对于1,000,000个请求:

休息用时62秒 SOAP耗时114秒

从“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的东西，比如字段级加密等。

我认为两者都有自己的位置。在我看来:

SOAP:传统/关键系统和web/web服务系统之间集成的更好选择，在基础层，其中WS-*是有意义的(安全，策略等)。

RESTful:一个更好的网站集成的选择，公共API，在层的顶部(VIEW，即javascript调用uri)。