SOAP体现了Web服务的面向服务的方法——在这种方法中，方法(或动词)是与服务交互的主要方式。REST采用面向资源的方法，其中对象(或名词)占据中心位置。

不要忽视XML-RPC。如果您只是追求一个轻量级的解决方案，那么对于一个可以在几页文本中定义并在最少的代码中实现的协议来说，有很多事情要做。XML-RPC已经存在了多年，但已经过时了一段时间——但是极简主义的吸引力似乎使它在最近得到了某种复兴。

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

还需要我继续说下去吗?

我写的大多数应用程序都是服务器端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是Roy Fielding发明的一种架构，并在他的论文《架构风格和基于网络的软件架构设计》中进行了描述。Roy也是HTTP协议的主要作者，该协议定义了在万维网上的文档传输。HTTP是RESTful协议。当开发人员谈论“使用REST Web服务”时，可能更准确的说法是“使用HTTP”。

SOAP是一种基于xml的协议，它在HTTP请求/响应中进行隧道传输，因此即使您使用SOAP，您也在使用REST。关于SOAP是否为基本HTTP添加了任何重要的功能存在一些争论。

在创建Web服务之前，我建议学习HTTP。很可能您的需求可以使用规范中已经定义的功能实现，因此不需要其他协议。

回答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服务可以被分类为 粗粒度和令人尴尬的并行。

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