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

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

有一件事没有提到，SOAP信封既可以包含头部，也可以包含主体部分。这使您可以使用XML的完整表达来发送和接收带外信息。据我所知，REST限制你使用HTTP头和结果代码。

(哦，你可以使用cookie和REST服务一起发送“头”类型的带外数据吗?)

REST是一个体系结构，SOAP是一个协议。

这是第一个问题。

您可以在REST应用程序中发送SOAP信封。

SOAP本身实际上是相当基本和简单的，它之上的WSS-*标准使它非常复杂。

如果您的消费者是其他应用程序和其他服务器，那么目前对SOAP协议有很多支持，在现代ide中移动数据的基本操作基本上就是单击鼠标。

如果您的消费者更有可能是ria或Ajax客户端，那么您可能希望使用比SOAP更简单、更适合客户端的东西(特别是JSON)。

通过HTTP发送的JSON包不一定是REST体系结构，它只是发送到url的消息。所有这些都是完全可行的，但是REST习惯用法有一些关键组件。然而，这两者很容易混淆。但是，仅仅因为您谈论的是HTTP请求，并不一定意味着您拥有REST体系结构。您可以有一个完全没有HTTP的REST应用程序(注意，这种情况很少见)。

因此，如果您的服务器和消费者对SOAP“满意”，SOAP和WSS堆栈就可以很好地为您服务。如果你在做一些特别的事情，想要更好地与web浏览器交互，那么一些轻量级的HTTP协议也可以很好地工作。

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

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

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