我建议您先使用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资源

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

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

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

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

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

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

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

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

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

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

我写的大多数应用程序都是服务器端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。

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

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