我的一般规则是，如果你想要一个浏览器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实际上是快速和简单的，适用于轻量级调用和响应，并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。

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

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

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

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

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

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

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

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

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

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

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

回答2012年刷新的问题(通过第二个赏金)，并回顾今天的结果(其他答案)。

---

SOAP的利弊

关于SOAP 1.2，与“REST”相比的优点和缺点…从2007年开始 你可以用WSDL描述REST Web服务， 并使用SOAP协议…也就是说，如果您再努力一点，web服务协议栈的所有W3C标准都可以是REST!

这是一个很好的起点，因为我们可以想象一个场景，在这个场景中，所有的哲学和方法论讨论都暂时被避免了。我们可以在技术上比较类似服务中的“SOAP-REST”和“非SOAP-REST”，

SOAP-REST (="REST-SOAP"): as showed by L.Mandel, WSDL2 can describe a REST webservice, and, if we suppose that exemplified XML can be enveloped in SOAP, all the implementation will be "SOAP-REST". NON-SOAP-REST: any REST web service that can not be SOAP... That is, "90%" of the well-knowed REST examples. Some not use XML (ex. typical AJAX RESTs use JSON instead), some use another XML strucutures, without the SOAP headers or rules. PS: to avoid informality, we can suppose REST level 2 in the comparisons.

当然，为了从概念上进行比较，可以将“NON-REST-SOAP”与“NON-SOAP-REST”作为不同的建模方法进行比较。那么，完成这个web服务分类:

NON-REST-SOAP:任何不能是REST的SOAP web服务…也就是说，“90%”的广为人知的SOAP示例。 NON-REST-NEITHER-SOAP:是的，“web服务建模”的世界包括其他东西(例如XML-RPC)。

REST条件下的SOAP

比较可比较的事物:皂歇和非皂歇。

PROS

解释一些术语，

Contractual stability: for all kinds of contracts (as "written agreements"), By the use of standars: all levels of the W3C stack are mutually compliant. REST, by other hand, is not a W3C or ISO standard, and have no normatized details about service's peripherals. So, as I, @DaveWoldrich(20 votes), @cynicalman(5), @Exitos(0) said before, in a context where are NEED FOR STANDARDS, you need SOAP. By the use of best practices: the "verbose aspect" of the W3C stack implementations, translates relevant human/legal/juridic agreements. Robustness: the safety of SOAP structure and headers. With metada communication (with the full expressiveness of XML) and verification you have an "insurance policy" against any changes or noise. SOAP have "transactional reliability (...) deal with communication failures. SOAP has more controls around retry logic and thus can provide more end-to-end reliability and service guarantees", E. Terman.

按受欢迎程度排序，

更好的工具(~70票):从2007年到2012年，SOAP目前拥有更好的工具的优势，因为它是一个定义良好且被广泛接受的标准。参见@MarkCidade(27票)，@DaveWoldrich(20票)，@JoshM(13票)，@TravisHeseman(9票)。 标准遵从性(25票):正如我，@DaveWoldrich(20票)，@愤世嫉俗的人(5票)，@Exitos(0票)之前所说，在需要标准的上下文中，您需要SOAP。 健壮性:SOAP头的保险，@JohnSaunders(8票)。

CONS

SOAP strucuture is more complex (more than 300 votes): all answers here, and sources about "SOAP vs REST", manifest some degree of dislike with SOAP's redundancy and complexity. This is a natural consequence of the requirements for formal verification (see below), and for robustness (see above). "REST NON-SOAP" (and XML-RPC, the SOAP originator) can be more simple and informal. The "only XML" restriction is a performance obstacle when using tiny services (~50 votes): see json.org/xml and this question, or this other one. This point is showed by @toluju(41), and others. PS: as JSON is not a IETF standard, but we can consider a de facto standard for web software community.

---

使用SOAP对服务建模

现在，我们可以添加SOAP- non - rest与非SOAP- rest比较，并解释什么时候使用SOAP更好:

Need for standards and stable contracts (see "PROS" section). PS: see a typical "B2B need for standards" described by @saille. Need for tools (see "PROS" section). PS: standards, and the existence of formal verifications (see bellow), are important issues for the tools automation. Parallel heavy processing (see "Context/Foundations" section below): with bigger and/or slower processes, no matter with a bit more complexity of SOAP, reliability and stability are the best investments. Need more security: when more than HTTPS is required, and you really need additional features for protection, SOAP is a better choice (see @Bell, 32 votes). "Sending the message along a path more complicated than request/response or over a transport that does not involve HTTP", S. Seely. XML is a core issue, offering standards for XML Encryption, XML Signature, and XML Canonicalization, and, only with SOAP you can to embed these mechanisms into a message by a well-accepted standard as WS-Security. Need more flexibility (less restrictions): SOAP not need exact correspondence with an URI; not nedd restrict to HTTP; not need to restrict to 4 verbs. As @TravisHeseman (9 votes) says, if you wanted something "flexible for an arbitrary number of client technologies and uses", use SOAP.PS: remember that XML is more universal/expressive than JSON (et al). Need for formal verifications: important to understand that W3C stack uses formal methods, and REST is more informal. Your WSDL (a formal language) service description is a formal specification of your web services interfaces, and SOAP is a robust protocol that accept all possible WSDL prescriptions.

上下文

历史

要判断趋势，必须有历史的眼光。对于这个问题，10年或15年的展望……

在W3C标准化之前，有一些混乱。很难用不同的框架实现可互操作的服务，而在公司之间实现一些可互操作的东西则更加困难、昂贵和耗时。 W3C堆栈标准一直是复杂web服务集互操作的明灯。

对于日常的任务，比如实现AJAX, SOAP很繁重……因此，需要简单的方法，需要选择一个新的理论框架…而大的“网络软件玩家”，如谷歌、亚马逊、雅虎等，选出了最佳的替代方案，那就是REST方法。在这种情况下，REST概念作为一个“竞争性框架”出现了，并且，今天(2012年)，这个替代方案已经成为程序员的事实上的标准。

基金会

在并行计算环境下，web服务提供并行子任务;和协议，如SOAP，确保良好的同步和通信。不是“任何任务”:web服务可以被分类为 粗粒度和令人尴尬的并行。

随着任务变得越来越大，“复杂性争论”变得不那么重要，而与通信的稳健性和合同的稳固性更加相关。