这是微妙的。

如果您需要让其他系统与您的服务进行接口，那么由于您使用契约、WSDL和SOAP标准所拥有的“验证”层，许多客户端将更乐于使用SOAP。

对于日常系统对系统的调用，我认为SOAP是很多不必要的开销，而简单的HTML调用就可以了。

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

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

如果您正在寻找不同系统和语言之间的互操作性，我肯定会选择REST。例如，在尝试让SOAP在. net和Java之间工作时，我遇到了很多问题。

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

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

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

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协议也可以很好地工作。

REST是一种与SOAP完全不同的范例。关于REST的一个很好的阅读可以在这里找到:我是如何向妻子解释REST的。

如果你没有时间阅读它，这里是一个简短的版本:REST是一个范式的转变，通过关注“名词”，并限制你可以应用于这些名词的“动词”的数量。唯一允许使用的动词是“get”、“put”、“post”和“delete”。这与SOAP不同，SOAP中许多不同的动词可以应用于许多不同的名词(即许多不同的功能)。

对于REST，四个动词映射到相应的HTTP请求，而名词则由url标识。这使得状态管理比SOAP更加透明，在SOAP中，服务器上的状态和客户端上的状态往往不清楚。

在实践中，尽管大部分都消失了，REST通常只是指简单的HTTP请求，返回JSON中的结果，而SOAP是一个更复杂的API，通过传递XML进行通信。两者都有各自的优点和缺点，但是根据我的经验，我发现REST通常是更好的选择，因为您很少需要从SOAP获得的全部功能。

从工具的角度来看，SOAP很有用，因为工具很容易使用WSDL。因此，您可以用您喜欢的语言为您生成Web服务客户机。

REST在AJAX的网页上表现得很好。如果保持请求的简单性，就可以直接从JavaScript调用服务，这非常方便。尽量避免在响应XML中使用任何名称空间，我看到浏览器在使用这些名称空间时会窒息。因此，xsi:type可能不适合您，没有过于复杂的XML schema。

REST往往也有更好的性能。生成REST响应的代码对CPU的要求往往比SOAP框架所展示的要低。而且，如果在服务器端安排了XML生成流程，就可以有效地将XML流输出到客户机。假设您正在读取数据库游标中的行。在读取一行时，将其格式化为XML元素，并将其直接写入服务使用者。通过这种方式，您不必在开始写入XML输出之前收集内存中的所有数据库行—您可以同时读取和写入。研究新的模板引擎或XSLT，使流能够为REST工作。

另一方面，SOAP往往是由工具生成的服务生成的一个大blob，然后才编写。请注意，这并不是绝对的事实，有很多方法可以从SOAP中获得流特性，比如使用附件。

我的决策过程如下:如果我想让我的服务易于被消费者使用，并且我编写的消息将是中等到小型的(10MB或更小)，并且我不介意在服务器上消耗一些额外的CPU周期，那么我就使用SOAP。如果我需要在web浏览器上使用AJAX，或者我需要进行流式处理，或者我的响应非常大，我就使用REST。

最后，围绕SOAP建立了许多很棒的标准，如WS-Security和获得有状态的Web服务，如果使用正确的工具，可以将它们插入。这类东西真的很重要，可以帮助您满足一些棘手的要求。

我相信Don Box创建SOAP是一个笑话——“看你可以在web上调用RPC方法”，今天当他意识到它已经成为一个臃肿的web标准的噩梦时，他会呻吟:-)

REST很好，很简单，在任何地方都可以实现(所以它更像是一个“标准”，而不是标准)，又快又简单。使用REST。

当我在惠普工作时，我根据开发中的原始规范构建了第一批SOAP服务器之一，包括代码生成和WSDL生成。我不建议在任何事情上使用SOAP。

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

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

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

我建议你先用REST——如果你使用Java，看看JAX-RS和泽西岛实现。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资源

请收听这个播客来找出答案。如果你想在不听的情况下知道答案，那么好吧，这是REST。但我真的建议你听。

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

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

我写的大多数应用程序都是服务器端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而不是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实际上是快速和简单的，适用于轻量级调用和响应，并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。

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

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

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

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

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

REST是Roy Fielding发明的一种架构，并在他的论文架构风格与基于网络的软件架构设计中进行了描述。Roy也是HTTP协议的主要作者，该协议定义了在万维网上的文档传输。HTTP是RESTful协议。当开发人员谈论“使用REST Web服务”时，可能更准确的说法是“使用HTTP”。

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

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

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

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

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

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

SOAP的利弊

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

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

• SOAP-REST (=" REST-SOAP"):作为曼德尔的作品, WSDL2可以描述一个REST web服务，并且，如果我们假设示例XML可以被封装在SOAP中，那么所有的实现都将是“SOAP-REST"”

• NON-SOAP-REST:不能是SOAP的任何REST web服务…即“90%”;众所周知的REST示例。有些不使用XML(例如，典型的AJAX rest使用JSON代替)，有些使用另一种XML结构，没有SOAP头或规则。注:为了避免非正式，我们可以在比较中假设REST级别2。

当然，为了在概念上进行比较，可以比较“non - rest - soap”;使用“non - soap - rest”，作为不同的建模方法。那么，完成这个web服务分类:

• NON-REST-SOAP:任何不能是REST的SOAP web服务…即“90%”;众所周知的SOAP示例。

• NON-REST-NEITHER-SOAP:是的，“web服务建模”的宇宙;包含其他东西(例如xml - rpc)。

REST条件下的SOAP

比较可比较的东西:SOAP-REST和NON-SOAP-REST。

优点

解释一些术语，

• 合同的稳定性:对于所有类型的合同(如“书面协议”)，

  • 通过标准的使用: W3C堆栈的所有级别是相互兼容的。另一方面，REST不是W3C或ISO标准，没有关于服务外围设备的规范化细节。所以，正如我， @DaveWoldrich(20票)，@愤世嫉俗的人(5票)，@Exitos(0票)之前说过的，在需要标准的上下文中，你需要SOAP。

  • 通过最佳实践的使用:“verbose方面”;的W3C堆栈实现，翻译相关的人力/法律/司法协议。

• 鲁棒性: SOAP结构和头的安全性。有了元数据通信(XML的完整表达)和验证，你就有了一个“保险单”;反对任何变化或噪音。SOAP有“事务可靠性(…)”来处理通信故障。SOAP对重试逻辑有更多的控制，因此可以提供更多的端到端可靠性和服务保证。

按受欢迎程度排序，

• 更好的工具(~70票):SOAP目前拥有更好的工具的优势，从2007年到2012年，因为它是一个定义良好且被广泛接受的标准。参见@MarkCidade(27票)，@DaveWoldrich(20票)，@JoshM(13票)，@TravisHeseman(9票)。

• 标准遵从性(25票):正如我， @DaveWoldrich(20票)，@ alman(5票)，@Exitos(0票)之前所说，在需要标准的上下文中，你需要SOAP。

• 鲁棒性: SOAP头的保险，@JohnSaunders(8票)。

缺点

• SOAP结构更加复杂(超过300票):这里的所有答案，以及关于“SOAP vs rest”的来源，都在一定程度上表现出对SOAP的冗余和复杂性的厌恶。这是形式验证(见下文)和鲁棒性(见上文)需求的自然结果。“其他NON-SOAP"(和XML-RPC， SOAP发起者)可以更简单和非正式。

• “仅xml”;限制是一种性能障碍当使用微型服务(~50票):见json.org/xml和这个问题，或另一个。这一点由@toluju(41)和其他人展示。PS:作为JSON不是IETF标准，但我们可以考虑为web软件社区的事实上的标准。

使用SOAP对服务建模

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

• 需要标准和稳定的合同(见"PROS"部分)。PS:见典型的B2B需求标准;由@saille描述。

• 工具需求(参见"PROS"部分)。PS: 标准和正式的验证的存在(见下文)是工具自动化的重要问题。

• 并行重加工(参见“上下文/基础”;小节):对于更大和/或更慢的流程，无论SOAP是否稍微复杂一点，可靠性和稳定性都是最好的投资。

• 需要更多的安全保障:当需要的不仅仅是HTTPS，而且你确实需要额外的功能来保护时，SOAP是更好的选择(看到@Bell, 32票)。“沿着比请求/响应更复杂的路径发送消息或通过不涉及http2的传输”，美国西利。XML是一个核心问题，它为XML加密、XML签名和XML规范化提供了标准，而且，只有使用SOAP，你才能通过公认的ws - security标准将这些机制嵌入到消息中。

• 需要更多的灵活性(较少限制):SOAP不需要与URI精确对应;不需要限制HTTP;不需要限制在4个动词。正如@TravisHeseman(9票)说的，如果你想要一种“对任意数量的客户端技术和用途都灵活”的东西，那就使用SOAP。PS:记住XML比JSON(等)更通用/更具表现力。

• 需要正式验证:重要的是要理解W3C堆栈使用正式的方法，而REST更非正式。你的WSDL (正式的语言)服务描述是你的web服务接口的正式规范, SOAP是一个健壮的协议，接受所有可能的WSDL规定。

上下文

历史

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

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

基金会

当任务变大时，“复杂性争论”就变得不那么重要，而与沟通的稳健性和合同的稳固性更加相关。

快速了解一下2012年的问题:

REST在以下方面发挥了很好的作用:

• 带宽和资源有限。记住返回结构实际上是任何格式(开发者定义)。另外，任何浏览器都可以使用，因为REST方法使用标准的GET、PUT、POST和DELETE动词。请再次记住，REST还可以使用大多数现代浏览器支持的XMLHttpRequest对象，这为AJAX增加了额外的好处。

• 完全无状态操作。如果一个操作需要继续，那么REST不是最好的方法，SOAP可能更适合它。但是，如果您需要无状态的CRUD(创建、读取、更新和删除)操作，那么REST就是最佳选择。

• < >强缓存的情况。如果由于REST方法的完全无状态操作，信息可以被缓存，这是完美的。这涵盖了上面三个中的许多解决方案。

那么我为什么要考虑SOAP呢?同样，SOAP是相当成熟和定义良好的，并且带有完整的规范。REST方法就是这样一种方法，它对开发非常开放，所以如果你具备以下条件，那么SOAP就是一个很好的解决方案:

• 异步处理和调用。如果您的应用程序需要有保证的可靠性和安全性级别，那么SOAP 1.2提供了额外的标准来确保这种类型的操作。比如WSRM - WS-Reliable Messaging。

• < >强正式合同。如果双方(提供者和使用者)必须就交换格式达成一致，那么SOAP 1.2为这种类型的交互提供了严格的规范。

• < >强有状态操作。如果应用程序需要上下文信息和会话状态管理，那么SOAP 1.2在WS*结构中有额外的规范来支持这些事情(安全、事务、协调等)。相比之下，REST方法将使开发人员构建这种自定义管道。

http://www.infoq.com/articles/rest-soap-when-to-use-each

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

从“PHP-宇宙”的意义上讲，PHP对任何高级SOAP的支持都很糟糕。一旦您满足了基本需求，您将最终使用类似http://wso2.com/products/web-services-framework/php/的东西，甚至启用没有内置支持的WS-Security或WS-RM。

我觉得在PHP中创建SOAP信封是非常混乱的，它创建命名空间的方式，xsd:nil, xsd:anytype和老式的SOAP服务使用SOAP编码(上帝知道这有什么不同)与SOAP消息。

通过坚持REST来避免所有这些混乱，REST并不是什么大不了的东西，我们从WWW开始就在使用它。只有当这篇http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm论文发表时，我们才意识到它展示了如何使用HTTP功能来实现RESTFul服务。HTTP本质上是REST，这并不意味着仅仅使用HTTP就可以使您的服务RESTFul。

SOAP忽略了HTTP的核心功能，只将HTTP视为传输协议，因此理论上它是独立于传输协议的(实际上并非如此，您听说过SOAP Action报头吗?如果不是现在!)。

随着JSON适应的增加以及HTML5和javascript的成熟，REST和JSON已经成为处理服务的最常见方式。JSON Schema也被定义为可以在需要时与WADL一起用于企业级解决方案(仍处于早期阶段)。

PHP对REST和JSON的支持肯定比现有的内置SOAP支持更好。

在这里添加更多的术语SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

顺便说一下，我非常喜欢SOAP，特别是WS-Security规范，这是一个很好的规范，如果有人在考虑企业JSON适应肯定需要一些类似JSON的东西，比如字段级加密等。

我的一般规则是，如果你想要一个浏览器web客户端直接连接到一个服务，那么你可能应该使用REST。如果希望在后端服务之间传递结构化数据，则使用SOAP。

SOAP的设置有时真的很痛苦，对于简单的web客户端和服务器数据交换来说，它通常是多余的。不幸的是，我所见过(并从中学到)的大多数简单编程示例都在某种程度上强化了这种看法。

也就是说，当您开始将多个SOAP服务作为数据工作流(想想企业软件)驱动的更大流程的一部分组合在一起时，SOAP才能真正发挥作用。这是许多SOAP编程示例无法传达的内容，因为一个简单的SOAP操作(如获取股票价格)本身通常过于复杂，除非它是在提供机器可读API的上下文中提供的，该API详细描述了特定函数，并为输入和输出设置了数据格式，而这些输入和输出又由更大的进程编写脚本。

在某种程度上，这是可悲的，因为它确实给SOAP带来了坏名声，因为如果不在最终产品如何使用的完整上下文中展示它，就很难展示SOAP的优点。