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

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

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

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

我建议您先使用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服务器之一，包括代码生成和WSDL生成。我不建议在任何事情上使用SOAP。

首字母缩写“SOAP”是一个谎言。它不是简单的，它不是面向对象的，它没有定义访问规则。可以说，它是一项议定书。这是Don Box有史以来最糟糕的规格，这是一个相当了不起的壮举，因为他是“COM”的创造者。

SOAP中没有什么有用的东西是REST不能用于传输的，JSON、XML甚至纯文本不能用于数据表示的。为了传输安全，可以使用https协议。对于认证，使用基本认证。对于会话，有cookie。REST版本将更简单、更清晰、运行更快、使用更少的带宽。

XML-RPC清楚地定义了请求、响应和错误协议，并且对于大多数语言都有很好的库。但是，对于许多任务来说，XML比您所需要的要重。

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

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

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

这是个好问题……我不想让你误入歧途，所以我和你一样愿意接受别人的答案。对我来说，这实际上归结于开销成本和API的使用。在创建客户端软件时，我更喜欢使用web服务，但是我不喜欢SOAP的重量。我相信REST的重量更轻，但我不太喜欢从客户的角度使用它。

我很好奇别人是怎么想的。