用于Web服务的SOAP还是REST？
REST是做Web服务还是SOAP的更好方法？ 或者他们是不同的工具来解决不同的问题 或者这是一个细微的问题 – 也就是说，在某些领域比另一个领域略胜一筹？
赏金编辑：
现在，差不多三年后，我想再次提出这个问题 – 提供一个奖励，鼓励一个深入的答案。 我特别感谢有关这些概念及其与PHP世界以及现代高端Web应用程序的关系的信息。
当我在惠普工作时，我开发了其中一个最初的SOAP服务器，包括代码生成和WSDL生成。 我不build议使用SOAP来做任何事情。
首字母缩写“SOAP”是一个谎言。 它不是简单的，它不是面向对象的，它没有定义访问规则。 它可以说是一个议定书。 这是Don Box的最糟糕的规格，这是一个相当大的成就，因为他是犯下“COM”的人。
在SOAP中没有什么用处，用REST进行传输是不可能的，JSON，XML甚至纯文本用于数据表示。 为了运输安全，您可以使用https。 对于身份validation，基本身份validation。 对于会议，有cookies。 REST版本将更简单，更清晰，运行更快，并使用更less的带宽。
XML-RPC明确地定义了请求，响应和错误协议，并且大多数语言都有很好的库。 但是，XML比许多任务所需要的要重。
REST是一种架构，SOAP是一种协议。
这是第一个问题。
您可以在REST应用程序中发送SOAP信封。
SOAP本身实际上是非常基本和简单的，它的WSS- *标准使它非常复杂。
如果您的客户是其他应用程序和其他服务器，那么当前对SOAP协议有很多支持，移动数据的基础实质上是在现代IDE中的鼠标点击。
如果您的客户更可能成为RIA或Ajax客户端，那么您可能会想要比SOAP更简单的一些东西，而且更多的是客户端本地（特别是JSON）。
通过HTTP发送的JSON数据包不一定是REST架构，它只是向URL发送消息。 所有完全可行的，但有关键组件的REST成语。 然而，容易混淆两者。 但是，仅仅因为你说的HTTP请求并不一定意味着你有一个REST架构。 你可以有一个没有HTTP的REST应用程序（介意，这很less见）。
所以，如果你的服务器和消费者对SOAP感到“舒服”，那么SOAP和WSS栈可以很好地为你服务。 如果你正在做更多的特别的事情，并希望更好地与networking浏览器接口，那么一些较轻的HTTP协议也可以很好地工作。
REST与SOAP有着根本不同的范例。 关于REST的一个很好的阅读可以在这里find： 我如何向我的妻子解释REST 。
如果你没有时间阅读它，下面是一个简短的版本：REST通过关注“名词”和限制可以应用于这些名词的“动词”的数量来进行范式转换。 唯一允许的动词是“get”，“put”，“post”和“delete”。 这不同于SOAP，许多不同的动词可以应用于许多不同的名词（即许多不同的function）。
对于REST，这四个动词映射到相应的HTTP请求，而名词由URL标识。 这使得状态pipe理比SOAP更透明，其中通常不清楚服务器上的状态和客户端上的状态。
在实践中，虽然大部分情况都会消失，REST通常只是指以JSON返回结果的简单HTTP请求，而SOAP则是一个通过传递XML来进行通信的更复杂的API。 两者都有其优点和缺点，但是我发现以我的经验来说，REST通常是更好的select，因为你很less需要从SOAP获得的全部function。
2012年问题快速低调：
REST工作得很好的领域是：
-
有限的带宽和资源。 请记住，返回结构确实是任何格式（开发人员定义）。 另外，可以使用任何浏览器，因为REST方法使用标准的GET，PUT，POST和DELETE动词。 同样，请记住，REST还可以使用大多数现代浏览器支持的XMLHttpRequest对象，这增加了AJAX的额外好处。
-
完全无国籍的行动。 如果需要继续操作，那么REST并不是最好的方法，SOAP可能更好。 但是，如果您需要无状态CRUD（创build，读取，更新和删除）操作，那么REST就是这样。
-
caching情况。 如果由于REST方法的完全无状态操作而使得信息可以被caching，这是完美的。这涵盖了上述三个方面的很多解决scheme。
那么为什么我会考虑SOAP呢？ 同样，SOAP是相当成熟和定义明确的，并且具有完整的规范。 REST方法就是这样一种方法，对于开发来说是广泛的，所以如果你有以下的东西，那么SOAP是一个很好的解决scheme：
-
asynchronous处理和调用。 如果您的应用程序需要可靠性和安全性的保证，那么SOAP 1.2提供了额外的标准来确保这种types的操作。 比如WSRM – WS-Reliable Messaging。
-
正式的合同。 如果双方（提供者和消费者）必须就交换格式达成一致，那么SOAP 1.2给出了这种交互types的严格规范。
-
有状态的操作。 如果应用程序需要上下文信息和会话状态pipe理，那么SOAP 1.2在WS *结构中具有附加规范来支持这些事情（安全，事务，协调等）。 相对而言，REST方法将使开发人员构build这个定制pipe道。
SOAP目前具有更好的工具的优势，在这些工具中，它们将为服务层生成大量的样板代码，并从任何给定的WSDL生成客户端。
REST更简单，因此可以更容易维护，位于Web体系结构的核心，允许更好的协议可见性，并且已经被certificate可以扩展到WWW本身的规模。 有些框架可以帮助您构buildREST服务，比如Ruby on Rails，有些甚至可以帮助您编写客户端，如ADO.NET Data Services。 但大多数情况下，缺less工具支持。
从工具的angular度来看，SOAP是有用的，因为WSDL很容易被工具所使用。 因此，您可以使用您最喜欢的语言为您生成Web Service客户端。
REST在AJAX的网页中performance良好。 如果您保持简单的请求，则可以直接使用JavaScript进行服务调用，而且非常方便。 尽量避免在你的响应XML中有任何命名空间，我已经看到浏览器扼杀这些。 所以，xsi：type可能不适合你，没有太复杂的XML Schema。
REST也往往有更好的performance。 生成REST响应的代码的CPU需求往往低于SOAP框架所展现的。 而且，如果您在服务器端排队放置XML代码，则可以将XML有效地传输到客户端。 所以，想象你正在阅读数据库游标的行。 在读取一行时，将其格式化为XML元素，然后直接写入服务使用者。 这样，在开始编写XML输出之前，您不必收集内存中的所有数据库行，而是同时读取和写入。 看看新的模板引擎或XSLT，让stream媒体工作的REST。
另一方面，SOAP往往是由工具生成的服务生成的一个大块，然后才写成。 这不是一个绝对的事实，请记住，有一些方法可以通过使用附件从SOAP中获取stream式特征。
我的决策过程如下：如果我希望我的服务能够被消费者轻松pipe理，而且我写的信息是中小型（10MB或更less），我不介意烧一些额外的CPU在服务器上循环，我去用SOAP。 如果我需要在Web浏览器上服务于AJAX，或者我需要stream式传输，或者我的响应是巨大的，那我就去REST。
最后，围绕SOAP构build了许多伟大的标准，比如WS-Security和获得有状态的Web服务，如果您使用的是正确的工具，则可以插入到这些标准中。 这种东西真的有所作为，可以帮助你满足一些毛茸茸的要求。
我知道这是一个老问题，但我必须发表我的答案 – 也许有人会觉得它有用。 我无法相信有多less人推荐使用SOAP的REST。 我只能假设这些人不是开发人员，或者从来没有实际执行任何合理大小的REST服务。 实现一个REST服务比实现一个SOAP服务要花费更多的时间。 最后它也变得更加混乱。 以下是我selectSOAP 99％的原因：
1）实现REST服务比实现SOAP服务花费的时间要长得多。 所有现代语言/框架/平台的工具都可以在WSDL中读取并输出代理类和客户端。 实现一个REST服务是通过手工完成的，通过阅读文档来获得这个服务。 此外，在实施这两项服务的同时，您还必须“猜测”什么会回来，因为没有真正的模式或参考文件。
2）为什么编写一个返回XML的REST服务呢？ 唯一的区别是，使用REST你不知道每个元素/属性代表的types – 你自己来实现它，并希望有一天一个string不会出现在你认为总是一个整数的字段中。 SOAP使用WSDL定义了数据结构，所以这是一个简单的事情。
3）我听说过使用SOAP的投诉，您有SOAP Envelope的“开销”。 在这个时代，我们真的需要担心less数几个字节吗？
4）我听说过REST，你可以将URLpopup到浏览器中查看数据。 当然，如果你的REST服务使用简单的或者没有authentication。 例如，Netflix服务使用OAuth，在您提交请求之前，您需要对事物进行签名和编码。
5）为什么我们需要每个资源的“可读”URL？ 如果我们使用一个工具来实现这个服务，我们真的关心实际的URL吗？
我需要继续吗？
我写的大多数应用程序都是服务器端的C＃或Java，或WinForms或WPF中的桌面应用程序。 这些应用程序往往需要比REST更丰富的服务API。 此外，我不想花费几分钟时间创build我的Web服务客户端。 WSDL处理客户端生成工具允许我实现我的客户端并继续增加业务价值。
现在，如果我正在为某些javascript ajax调用显式编写web服务，那么可能是在REST中; 只是为了了解客户端技术和利用JSON。 在我看来，从JavaScript使用的Web服务API可能不应该是非常复杂的，因为这种types的复杂性似乎更好地处理服务器端。
这样说，有一些SOAP客户端的JavaScript; 我知道jQuery有一个。 因此，SOAP 可以从JavaScript中利用; 只是不如返回JSONstring的REST服务。 所以，如果我有一个Web服务，我想要足够复杂，它是灵活的任意数量的客户端技术和用途，我会去与SOAP。
我build议你先使用REST – 如果你使用Java看看JAX-RS和Jersey实现。 REST更简单，易于在许多语言中互操作。
正如其他人在这个线程中所说的那样，当其他WS- *规范进来时，SOAP的问题就变得复杂了，如果你误入了WSDL，XSD，SOAP，WS-Addressing等错误的部分，就会出现无数的互操作问题。
判断REST v SOAP辩论的最好方法是在互联网上查看 – 几乎所有networking空间的大玩家，google，amazon，ebay，twitter等都倾向于使用和更喜欢RESTful API而不是SOAP。
使用REST的另一个好方法是可以在Web应用程序和REST前端之间重用大量代码和基础结构。 例如，使用JAX-RS和隐式视图之类的框架来渲染HTML与XML或JSON资源通常非常容易，而且使用Web浏览器可以轻松地使用RESTful资源
我确定Don Box创buildSOAP作为一个笑话 – “看你可以通过networking调用RPC方法”，今天当他意识到Web标准已经变成一个臃肿的恶梦时，他呻吟了一声:-)
REST很好，简单，无处不在（所以比标准更多的是“标准”）快速和简单。 使用REST。
我觉得这两个都有自己的位置。 我的想法是：
SOAP ：在WS-*有意义（安全性，策略等）的基础层上，传统/关键系统与Web / Web服务系统之间集成的更好select。
RESTful ：一个更好的select，使用公共API，在层的顶层（VIEW，也就是调用URI的javascript）上集成网站。
有一件没有提到的事情是SOAP信封可以包含标题以及正文部分。 这使您可以使用XML的充分performance力来发送和接收带外信息。 据我所知，REST限制你使用HTTP Headers和结果代码。
（otoh，您可以使用Cookie与REST服务发送“标题” – 带外数据？）
回答2012年（第二次赏金）的问题，并回顾今天的结果（其他答案）。
SOAP，优点和缺点
与“REST”相比，关于SOAP 1.2，优点和缺点…那么，自2007年以来， 您可以使用WSDL描述REST Web服务 ，并使用SOAP协议…也就是说，如果您工作起来有点困难， 所有W3C标准Web服务协议栈可以是REST ！
这是一个很好的起点，因为我们可以想象一个暂时避免所有哲学和方法论讨论的场景。 我们可以在技术上将“SOAP-REST”与类似服务中的“非SOAP-REST”进行比较，
-
SOAP-REST （=“REST-SOAP”）：如L.Mandel所示 ，WSDL2可以描述REST Web服务，如果我们假设示例XML可以封装在SOAP中，则所有的实现都将是“SOAP-REST” 。
-
非SOAP-REST ：任何不能成为SOAP的REST Web服务……也就是众所周知的REST示例的“90％”。 有些不使用XML（例如，典型的AJAX REST使用JSON代替），有些使用另一个XML结构，没有SOAP头或规则。 PS：为了避免非正式性，我们可以在比较中假设REST级别为2 。
当然，从概念上比较，比较“非REST-SOAP”和“非SOAP-REST”，作为不同的build模方法。 那么，完成这个Web服务的分类：
-
NON-REST-SOAP ：任何不能成为REST的SOAP Web服务…也就是众所周知的SOAP示例的“90％”。
-
NEST-REST-NEITHER-SOAP ：是的，“Web服务build模”的范围包含其他内容（如XML-RPC ）。
在REST中的SOAP矛盾
比较可比较的东西： SOAP-REST和NON-SOAP-REST 。
PROS
解释一些条款，
-
合同稳定性 ：对于各种合同（如“书面协议”），
-
通过使用标准 ： W3C协议栈的所有级别都是相互兼容的。 另一方面，REST不是W3C或ISO标准，也没有关于服务外设的规范化细节。 所以，就像我 ，@DaveWoldrich（20票），@cynicalman（5），@Exitos（0）之前所说的，在需要标准的情况下，你需要SOAP。
-
通过使用最佳实践 ： W3C堆栈实现的“冗长方面”，翻译相关的人权/法律/司法协议。
-
-
健壮性 ：SOAP结构和头部的安全性。 通过元数据交stream（具有XML的完整performance力）和validation，您可以有一个“保险策略”来应对任何变化或噪音。
SOAP具有“事务可靠性（…）来处理通信故障，SOAP对重试逻辑有更多的控制，因此可以提供更多的端到端可靠性和服务保证”， E. Terman 。
按受欢迎程度sorting优点，
-
更好的工具 （~70票）：SOAP目前有更好的工具的优势，自2007年以来，仍然是2012年，因为它是一个明确的，被广泛接受的标准。 请参阅@MarkCidade（27票），@DaveWoldrich（20），@JoshM（13），@TravisHeseman（9）。
-
Standar compliance （25票）：就像我 ，@DaveWoldrich（20票），@cynicalman（5），@Exitos（0）之前所说的，在需要标准的情况下，你需要SOAP。
-
健壮性 ：SOAP头的保险，@JohnSaunders（8票）。
缺点
-
SOAP结构更复杂 （超过300票）：这里的所有答案和关于“SOAP vs REST”的来源，都performance出对SOAP的冗余性和复杂性的某种程度的厌恶。 这是正式validation （见下文）的要求的自然结果，以及稳健性 （见上文）。 “REST非SOAP”（和XML-RPC， SOAP发起者 ）可以更加简单和非正式。
-
使用小型服务（ 〜50票）时，“仅限XML”限制是一个性能障碍 ：请参阅json.org/xml和这个问题 ，或者这个 问题 。 @toluju（41）等人表明了这一点。
PS：由于JSON不是IETF标准 ，但我们可以考虑一个事实上的networking软件社区标准 。
使用SOAPbuild模服务
现在，我们可以添加SOAP-NON-REST和NON-SOAP-REST比较，并解释何时使用SOAP更好 ：
-
需要标准和稳定的合同（见“PROS”部分）。 PS：参见@saille描述的一个典型的“B2B标准需求” 。
-
需要工具 （请参阅“PROS”部分）。 PS： 标准和正式validation （见下文）的存在是工具自动化的重要问题。
-
并行重处理 （请参阅下面的“上下文/基础”部分）：使用更大和/或更慢的进程，不pipe复杂性如何，SOAP的可靠性和稳定性都是最好的投资。
-
需要更多的安全性 ：当需要超过HTTPS，并且确实需要额外的保护function时，SOAP是更好的select（ 请参阅@Bell ，32票）。 “沿着比请求/响应更复杂的path发送消息，或通过不涉及HTTP的传输发送消息”， S. Seely 。 XML是一个核心问题，为XMLencryption ， XML签名和XML标准化提供标准，只有使用SOAP，才能将这些机制作为WS-Security以公认的标准embedded到消息中。
-
需要更多的灵活性 （更less的限制）：SOAP不需要与URI完全对应; 不限于HTTP; 不需要限制为4个动词。 正如@TravisHeseman（9票）所说，如果你想要“灵活的任意数量的客户端技术和用途”，使用SOAP。
PS：请记住，XML比JSON（等）更具普遍性/performance力。 -
需要正式的validation ：了解W3C堆栈使用正式方法很重要，而REST更为正式。 你的WSDL（一种正式的语言 ）服务描述是你的Web服务接口的一个正式的规范 ，SOAP是一个强大的协议，接受所有可能的WSDL规定。
CONTEXT
历史的
评估趋势是必要的历史视angular。 对于这个问题，10年或15年的观点…
在W3C标准化之前，有一些无政府状态。 很难实现具有不同框架的互操作服务，并且实现公司之间互操作的更困难，昂贵和耗时。 W3C的堆栈标准已经成为一套复杂的Web服务互操作的一个亮点。
对于日常工作来说，就像实施AJAX一样，SOAP是沉重的……所以，对简单方法的需求需要select一个新的理论框架……而大的“networking软件播放器”，如谷歌，亚马逊，雅虎等人select了最好的select，那就是REST方法。 在这种情况下，REST概念作为“竞争框架”而出现，而今天（2012年），这种替代scheme是程序员事实上的标准 。
基金会
在并行计算环境中，Web服务提供了并行的子任务; 和SOAP等协议确保了良好的同步和通信。 不是“任何任务”：networking服务可以被归类为
粗糙和尴尬的平行 。
随着任务越来越大，“复杂性辩论”变得越来越不重要，并且越来越关系到沟通的稳健性和合同的稳固性。
这是细微的。
如果您需要使用其他系统与您的服务进行交互，那么由于您使用合同，WSDL和SOAP标准进行的“validation”层，许多客户端会更喜欢使用SOAP。
对于调用系统的日常系统，我认为当一个简单的HTML调用可以完成时，SOAP是很多不必要的开销。
不要忽视XML-RPC。 如果你只是在一个轻量级的解决scheme之后，那么对于一个可以在几页文本中定义并且以最less量的代码实现的协议来说，这是一个很大的问题。 XML-RPC已经存在多年，但已经过时了一段时间 – 但最低限度的吸引力似乎是给了它近来的复兴。
REST是Roy Fielding发明的一种架构，在他的论文“ Architectural Styles and the Design of Network-based Software Architectures”中进行了描述 。 Roy也是HTTP的主要作者，该协议定义了万维网上的文档传输。 HTTP是一个RESTful协议。 当开发人员谈论“使用REST Web服务”时，说“使用HTTP”可能更准确。
SOAP是一种基于XML的协议，它在HTTP请求/响应中进行隧道传输，所以即使使用SOAP，也可以使用REST。 SOAP是否为基本的HTTP添加了任何重要的function都存在争议。
在编写Web服务之前，我会推荐学习HTTP。 可能是你的要求可以用规范中已经定义的function来实现，所以其他的协议是不需要的。
我正在看同样的，我认为， 他们是不同的问题的工具 。
简单对象访问协议（SOAP）标准是定义消息体系结构和消息格式的XML语言，由Web服务使用，它包含操作的描述。 WSDL是一种基于XML的语言，用于描述Web服务以及如何访问它们。 将在SMTP，HTTP，FTP等上运行。需要中间件支持，定义好的机制来定义像WSDL + XSD这样的服务，WS-Policy SOAP将返回基于XML的数据。SOAP提供安全性和可靠性的标准
具象状态传输（RESTful）Web服务。 他们是第二代Web服务。 REST风格的Web服务通过HTTP进行通信，而不是基于SOAP的服务，并且不需要XML消息或WSDL服务API定义。 对于REST，不需要中间件，只需要HTTP支持.WADL Standard，REST可以返回XML，纯文本，JSON，HTML等
许多types的客户端更容易使用RESTful Web服务，同时使服务器端发展和扩展。 客户可以select使用服务的一些或所有方面，并与其他基于Web的服务混搭。
- REST使用标准的HTTP，所以创build客户端，开发API是很简单的
- REST允许许多不同的数据格式，如XML，纯文本，JSON，HTML，而SOAP只允许XML。
- REST具有更好的性能和可伸缩性。
- rest，可以caching和SOAP不能
- 内置error handling，其中SOAP没有error handling
- REST是PDA和其他移动设备特别有用的。
REST服务很容易与现有网站集成。
SOAP具有一套协议，这些协议为安全性和可靠性等提供标准，并与其他符合WS的客户端和服务器进行交互操作。 SOAP Web服务（如JAX-WS）可用于处理asynchronous处理和调用。
对于复杂的API，SOAP将更加有用。
我正在看同样的问题。 在我看来，实际上REST是简单快捷的，对于轻量级的调用和响应来说是很好的，对于debugging来说也是非常有用的（比把URL传输到浏览器并看到响应更好）。
但是，REST似乎倒下来的事实是它不是一个标准（虽然它是由标准组成的）。 大多数编程库都有一种检查WSDL的方法，可以自动生成消费基于SOAP的服务所需的客户端代码。 到目前为止，基于REST的Web服务似乎是编写一个接口来匹配可能的调用的一种更为特殊的方法。 做一个手动的http请求，然后parsing响应。 这本身可能是危险的。
SOAP的优点在于，一旦发布了WSDL，业务就可以构造它们的逻辑aorund，通过设置契约，任何对接口的改变都会改变wsdl。 没有任何处理的空间。 您可以validation针对该WSDL的所有请求。 但是，由于WSDL不能正确描述REST服务，因此您没有定义通信接口的方式。
从商业的angular度来看，这似乎使沟通变得可以解释和改变，这似乎是一个坏主意。
在这个线程中的顶部“答案”似乎是说，SOAP代表简单的面向对象的访问协议，但是在维基看O意味着对象不面向对象。 他们是不同的东西。
我知道这个post很老，但是我认为我应该用我自己的发现来回应。
这是一个很好的问题…我不想把你引向歧途，所以我愿意和你一样向别人的答案敞开。 对我来说，这实际上归结为开销的成本以及API的用途。 我更喜欢在创build客户端软件时使用Web服务，但是我不喜欢SOAP的重要性。 我相信，REST的重量更轻，但我从客户angular度来看并不喜欢它。
我很好奇别人怎么想。
听这个播客找出来。 如果你想知道答案没有听，那么OK，它的REST。 但我真的推荐听。
我的一般规则是，如果你想要一个浏览器Web客户端直接连接到一个服务，那么你应该使用REST。 如果您想在后端服务之间传递结构化数据，则使用SOAP。
对于简单的Web客户端和服务器数据交换来说，SOAP有时会成为一个真正的痛苦，而且往往是矫枉过正的。 不幸的是，我所见过的大多数简单的编程示例（从中学到的东西）稍微强化了这种看法。
也就是说，当您开始将多个SOAP服务组合在一起时，SOAP真正发光，这是由数据工作stream驱动的更大stream程（思考企业软件）的一部分。 这是许多SOAP编程示例无法传达的，因为执行某项操作（如获取股票价格）的简单SOAP操作通常过于复杂，除非它是在提供机器的环境中呈现的可读的API详细描述了具有input和输出的设置数据格式的特定function，而这些input和输出又由更大的进程脚本化。
这在某种程度上是令人伤心的，因为它真的给SOAP带来了不好的声誉，因为如果不把它用在最终产品的使用方式的全部背景中，就很难展示SOAP的优点。
SOAP体现了面向服务的Web服务方法，其中方法（或动词）是您与服务交互的主要方式。 REST采用面向资源的方法，其中对象（或名词）占据中心位置。
从“PHP-宇宙”的意义上来说，对任何高级SOAP的PHP支持都很糟糕。 一旦您跨越基本需求，您将最终使用诸如http://wso2.com/products/web-services-framework/php/之类的东西，甚至可以使WS-Security或WS-RM无内置支持。;
SOAP信封的创build我觉得在PHP中很麻烦，它创build命名空间的方式，xsd：nil，xsd：anytype和旧样式的SOAP服务使用SOAP编码（上帝知道与SOAP消息有什么不同）。
通过坚持使用REST来避免所有这些混乱，自从WWW开始以来，REST就没有什么大的了。 我们只有在这个http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm文章出来的时候才意识到，它显示了我们如何使用HTTPfunction来实现RESTFul服务。; HTTP本质上是REST，并不意味着只是使用HTTP来使你的服务RESTFul。
SOAP忽略了HTTP的核心function，并认为HTTP只是一种传输协议，因此它在理论上是独立于传输协议的（实际上，你是否听说过SOAP Action头？如果现在不行的话）。
随着JSON自适应的增加和HTML5的日渐成熟，REST和JSON已经成为处理服务的最常见的方式。 如果需要，JSON模式也可以用于企业级解决scheme（还处于早期阶段）以及WADL。
对REST和JSON的PHP支持绝对比现有的内置SOAP支持更好。
在这里添加更多的BUZZ单词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规范，这是一个很好的规范，如果有人想在Enterprise JSON自适应中需要为JSON提供类似于JSON的东西，比如字段级encryption等。
一个快速点 – 传输协议和编排;
我使用基于TCP的SOAP来提高速度，可靠性和安全性，包括协调机器对机器服务（ESB）和外部服务。 更改服务定义，编排会从WSDL更改中引发一个错误，并立即显而易见，可以重build/部署。
不确定你可以用REST做同样的事情 – 我正在等待纠正或当然！ 使用REST，更改服务定义 – 直到它返回400（或其他）才知道。
如果你正在寻找不同的系统和语言之间的互操作性，我肯定会去REST。 例如，我在尝试使用.NET和Java之间的SOAP工作方面遇到了很多问题。
我创build一个基准，find他们哪个更快！ 我看到了这个结果：
对于1000个请求：
- REST花了3秒钟
- SOAP花了7秒
对于10,000个请求：
- REST花了33秒
- SOAP花了69秒
对于1,000,000个请求：
- REST花了62秒
- SOAP花了114秒
An old question but still relevant today….due to so many developers in the enterprise space still using it.
My work involves designing and developing IoT (Internet of Things) solutions. Which includes developing code for small embedded devices that communicate with the Cloud.
It is clear REST is now widely accepted and useful, and pretty much the defacto standard for the web, even Microsoft has REST support included throughout Azure. If I needed to rely on SOAP I could not do what I need to do, as is just too big, bulky and annoying for small embedded devices.
REST is simple and clean and small. Making it ideal for small embedded devices. I always scream when I am working with a web developer who sends me a WSDLs. As I will have to begin an education campaign about why this just isn't going to work and why they are going to have to learn REST.
1.From my experience. I would say REST gives you option to access the URL which is already built. eg-> a word search in google. That URL could be used as webservice for REST. In SOAP, you can create your own web service and access it through SOAP client.
- REST supports text,JSON,XML format. Hence more versatile for communicating between two applications. While SOAP supports only XML format for message communication.
