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

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

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

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

对于1000个请求:

休息用时3秒 SOAP耗时7秒

对于10,000个请求:

休息用时33秒 SOAP用时69秒

对于1,000,000个请求:

休息用时62秒 SOAP耗时114秒

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

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

不要忽视XML-RPC。如果您只是追求一个轻量级的解决方案，那么对于一个可以在几页文本中定义并在最少的代码中实现的协议来说，有很多事情要做。XML-RPC已经存在了多年，但已经过时了一段时间——但是极简主义的吸引力似乎使它在最近得到了某种复兴。

我的一般规则是，如果你想要一个浏览器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的优点。

1.从我的经验来看。我想说REST让你可以选择访问已经构建好的URL。>一个词搜索谷歌。该URL可以用作REST的web服务。 在SOAP中，您可以创建自己的web服务并通过SOAP客户机访问它。

REST支持文本、JSON、XML格式。因此，两个应用程序之间的通信更加通用。而SOAP仅支持XML格式的消息通信。