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

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

我写的大多数应用程序都是服务器端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——如果您正在使用Java，请查看JAX-RS和Jersey实现。REST更简单，易于在多种语言中进行互操作。

正如其他人在这篇文章中所说，SOAP的问题在于当其他WS-*规范加入时它的复杂性，如果您误入WSDL、xsd、SOAP、WS- addressing等的错误部分，就会出现无数的互操作问题。

判断REST和SOAP之争的最好方法是看看互联网——几乎所有网络领域的大玩家，谷歌、amazon、ebay、twitter等——都倾向于使用并偏爱RESTful api而不是SOAP api。

使用REST的另一个很好的方法是，你可以在web应用程序和REST前端之间重用大量的代码和基础设施。例如，使用JAX-RS和隐式视图等框架，将资源的HTML、XML和JSON呈现出来通常是非常容易的，而且使用web浏览器也很容易处理RESTful资源

我知道这是一个老问题，但我必须把我的答案贴出来——也许有人会发现它有用。我不敢相信有那么多人推荐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吗?

还需要我继续说下去吗?

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

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

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

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

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

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

快速了解一下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