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

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)标准，一种定义消息体系结构和消息格式的XML语言，被Web服务使用，它包含对操作的描述。WSDL是一种基于xml的语言，用于描述Web服务以及如何访问它们。将运行在SMTP,HTTP,FTP等。需要中间件支持，定义良好的机制来定义服务，如WSDL+XSD, WS-Policy SOAP将返回基于XML的数据，SOAP为安全性和可靠性提供标准

具象状态传输(RESTful) web服务。它们是第二代Web服务。基于rest的web服务通过HTTP而不是基于soap的服务进行通信，并且不需要XML消息或WSDL服务api定义。对于REST，不需要中间件，只需要HTTP支持。WADL标准，REST可以返回XML，纯文本，JSON, HTML等

对于许多类型的客户端来说，使用基于rest的web服务更容易，同时使服务器端能够演进和扩展。客户端可以选择使用服务的部分或全部方面，并将其与其他基于web的服务混合。

REST使用标准HTTP，因此创建客户端和开发api更简单 REST允许许多不同的数据格式，如XML、纯文本、JSON、HTML，而SOAP只允许XML。 REST具有更好的性能和可伸缩性。 休息并且可以缓存，而SOAP不能 内置错误处理，SOAP没有错误处理 REST在PDA和其他移动设备上特别有用。

REST是一种容易与现有网站集成的服务。

SOAP有一组协议，其中提供了安全性和可靠性标准，并与其他符合WS的客户机和服务器进行互操作。 SOAP Web服务(如JAX-WS)在处理异步处理和调用方面很有用。

对于复杂的API, SOAP会更有用。

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

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

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

我写的大多数应用程序都是服务器端c#或Java，或者WinForms或WPF中的桌面应用程序。这些应用程序往往需要比REST所能提供的更丰富的服务API。另外，我不想在创建web服务客户机上花费超过几分钟的时间。WSDL处理客户端生成工具允许我实现我的客户端并继续添加业务价值。

现在，如果我为一些javascript ajax调用显式地编写web服务，它可能是在REST中;只是为了了解客户端技术和利用JSON。在我看来，从javascript中使用的web服务api可能不应该非常复杂，因为这种类型的复杂性似乎可以更好地处理服务器端。

也就是说，javascript有一些SOAP客户端;我知道jQuery有一个。因此，SOAP可以从javascript中利用;只是不像REST服务返回JSON字符串那样好。因此，如果我有一个web服务，我希望它足够复杂，能够灵活地适应任意数量的客户端技术和用途，那么我会选择SOAP。

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

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

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

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

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

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