关于SOAP 1.2，与"REST"相比的优点和缺点......好吧，自2007年you can describe REST Web services with WSDL，并使用SOAP协议......也就是说，如果你的工作稍微努力， all W3C standards of the web services protocol stack can be REST ！
健壮性：SOAP结构和头文件的安全性 . 通过metada通信（具有完整的XML表达能力）和verification，您可以对任何更改或噪音进行"insurance policy" . SOAP有"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 .
SOAP strucuture is more complex （超过300票）：这里的所有答案以及有关"SOAP vs REST"的消息来源都表现出对SOAP冗余和复杂性的某种程度的厌恶 . 这是形式验证要求（见下文）和稳健性（见上文）的自然结果 . "REST NON-SOAP"（和XML-RPC，SOAP originator）可以更简单和非正式 .
需要更多安全性：当需要超过HTTPS时，您确实需要其他功能来保护，SOAP是更好的选择（see @Bell，32票） . "Sending the message along a path more complicated than request/response or over a transport that does not involve HTTP"，S. Seely . XML是一个核心问题，为XML加密，XML签名和XML规范化提供标准，并且只有使用SOAP，您才能通过广为接受的WS-Security标准将这些机制嵌入到消息中 .
需要更多灵活性（更少限制）：SOAP不需要与URI精确对应;没有限制到HTTP;不需要限制为4个动词 . 正如@TravisHeseman（9票）所说，如果你想要"flexible for an arbitrary number of client technologies and uses"，请使用SOAP . PS：请记住，XML比JSON（等人）更具普遍性和表现力 .
对于日常工作，比如实施AJAX，SOAP很重要......所以，需要简单的方法需要选择一个新的理论框架......而且大的"Web software players"，如谷歌，亚马逊，雅虎等，选择最好的替代方案，即REST方法 . 在这种情况下，REST概念是以"competing framework"形式出现的，今天（2012年），这种替代方案对于程序员来说是一个de facto standard .
28 回答
1.根据我的经验 . 我会说REST为您提供了访问已构建的URL的选项 . eg-> google中的单词搜索 . 该URL可用作REST的Web服务 . 在SOAP中，您可以创建自己的Web服务并通过SOAP客户端访问它 .
当我在Hewlett-Packard工作时，我从原始规范中构建了第一个SOAP服务器之一，包括代码生成和WSDL生成 . 我建议不要使用SOAP .
首字母缩略词“SOAP”是谎言 . 它不是简单的，它不是面向对象的，它没有定义Access规则 . 它可以说是一个议定书 . 这是Don Box有史以来最糟糕的规格，这是一个非常壮举，因为他是犯下“COM”的人 .
在SOAP中没有什么用处不能通过REST进行传输，JSON，XML甚至是用于数据表示的纯文本 . 对于传输安全性，您可以使用https . 对于身份验证，基本身份验证 . 对于会话，有cookie . REST版本将更简单，更清晰，运行更快，并且使用更少的带宽 .
XML-RPC明确定义了请求，响应和错误协议，并且大多数语言都有很好的库 . 但是，XML比许多任务所需的重 .
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的好读物：How I explained REST to my wife .
如果你没有时间阅读它，这里是简短的版本：通过专注于“名词”，限制你可以应用于那些名词的“动词”的数量，REST是一种范式转换 . 唯一允许的动词是“get”，“put”，“post”和“delete” . 这与SOAP不同，其中许多不同的动词可以应用于许多不同的名词（即许多不同的功能） .
对于REST，四个谓词映射到相应的HTTP请求，而名词由URL标识 . 这使得状态管理比SOAP更加透明，因为SOAP通常不清楚服务器上的状态以及客户端上的状态 .
实际上，虽然大多数情况都会消失，但REST通常只是指在JSON中返回结果的简单HTTP请求，而SOAP是通过传递XML进行通信的更复杂的API . 两者都有它们的优点和缺点，但我发现根据我的经验，REST通常是更好的选择，因为你很少需要从SOAP获得的全部功能 .
快速下降2012年问题：
REST非常适合的领域是：
Limited bandwidth and resources. 请记住，返回结构实际上是任何格式（开发人员定义） . 此外，可以使用任何浏览器，因为REST方法使用标准的GET，PUT，POST和DELETE动词 . 同样，请记住，REST也可以使用大多数现代浏览器目前支持的XMLHttpRequest对象，这增加了AJAX的额外奖励 .
Totally stateless operations. 如果需要继续操作，那么REST不是最好的方法，SOAP可能更适合它 . 但是，如果您需要无状态CRUD（创建，读取，更新和删除）操作，那么REST就是它 .
Caching situations. 如果由于REST方法的完全无状态操作而可以缓存信息，这是完美的 . 这涵盖了上述三种解决方案中的许多解决方案 .
那我为什么还要考虑SOAP呢？同样，SOAP相当成熟且定义明确，并且具有完整的规范 . REST方法就是这样一种方法，并且对于开发是开放的，所以如果你有以下内容，那么SOAP是一个很好的解决方案：
Asynchronous processing and invocation. 如果你的应用程序需要有保证的可靠性和安全性，然后SOAP 1.2提供了额外的标准来确保这种类型的操作 . 像WSRM - WS-Reliable Messaging之类的东西 .
Formal contracts. 如果双方（提供者和消费者）必须就交换格式达成一致，那么SOAP 1.2为这种类型的交互提供了严格的规范 .
Stateful operations. 如果应用程序需要上下文信息和会话状态管理，则SOAP 1.2在WS *结构中具有附加规范以支持这些内容（安全性，事务，协调等） . 相比之下，REST方法将使开发人员构建这种自定义管道 .
http://www.infoq.com/articles/rest-soap-when-to-use-each
SOAP 目前具有更好工具的优势，它们将为服务层生成许多样板代码，并从任何给定的WSDL生成客户端 .
REST 更简单，因此可以更容易维护，位于Web架构的核心，允许更好的协议可见性，并且已被证明可以按照WWW本身的大小进行扩展 . 有些框架可以帮助你构建REST服务，比如Ruby on Rails，有些甚至可以帮助你编写客户端，比如ADO.NET Data Services . 但在大多数情况下，缺乏工具支持 .
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 Build 了许多很好的标准，比如WS-Security和获取有状态的Web服务，如果你使用正确的工具，你可以插入它们 . 这种东西真的有所作为，可以帮助你满足一些毛茸茸的要求 .
REST是Roy Fielding发明的一种架构，在他的论文_873768中有所描述 . Roy也是HTTP的主要作者 - 该协议定义了万维网上的文档传输 . HTTP是一种RESTful协议 . 当开发人员谈论"using REST Web services"时，可能更准确地说"using HTTP."
SOAP是一种基于XML的协议，它在HTTP请求/响应中进行隧道传输，因此即使您使用SOAP，也使用REST . 关于SOAP是否为基本HTTP添加任何重要功能存在争议 .
在创作Web服务之前，我建议学习HTTP . 可能的情况是您的要求可以使用规范中已定义的功能来实现，因此不需要其他协议 .
我知道这是一个老问题，但我必须发布我的答案 - 也许有人会觉得它很有用 . 我无法相信有多少人推荐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处理客户端生成工具允许我实现我的客户端并继续增加业务 Value .
现在，如果我为一些javascript ajax调用显式编写Web服务，它可能在REST中;只是为了了解客户端技术并利用JSON . 在我看来，从javascript使用的Web服务API可能不应该非常复杂，因为这种类型的复杂性似乎更好地处理服务器端 .
话虽如此，有一些用于javascript的SOAP客户端;我知道jQuery有一个 . 因此，SOAP可以从javascript中利用;只是不如返回JSON字符串的REST服务那么好 . 因此，如果我有一个我想要足够复杂的Web服务，它对于任意数量的客户端技术和用途都是灵活的，那么我将使用SOAP .
我'd recommend you go with REST first - if you'使用Java查看JAX-RS和Jersey实现 . REST更加简单，易于在多种语言中互操作 .
正如其他人在这个帖子中所说的那样，SOAP的问题在于其他WS- *规范进入时的复杂性，如果你误入了WSDL，XSD，SOAP，WS-Addressing等错误的部分，就会出现无数的互操作问题 .
判断REST v SOAP争论的最佳方式是在互联网上看 - 几乎所有网络空间中的大玩家，谷歌，亚马逊，ebay，twitter等都倾向于使用和优先于SOAP的RESTful API .
使用REST的另一个好方法是，您可以在Web应用程序和REST前端之间重用大量代码和基础结构 . 例如使用JAX-RS和隐式视图等框架渲染HTML与XML而不是资源的JSON通常非常简单 - 而且使用Web浏览器很容易使用RESTful资源
我看起来你可以通过网络调用RPC方法了，今天当他意识到Web标准变得臃肿的噩梦时，今天呻吟:-)
REST很好，很简单，在任何地方实现（比标准更“标准”）快速而简单 . 使用REST .
我认为两者都有自己的位置 . 在我看来：
SOAP ：遗留/关键系统与Web / Web服务系统之间的集成的更好选择，在基础层上，WS- *有意义（安全性，策略等） .
RESTful ：使用公共API在网站顶层（VIEW，即javascripts调用URI）之间进行集成的更好选择 .
没有提到的一件事是SOAP信封可以包含 Headers 和正文部分 . 这使您可以使用XML的完整表现力来发送和接收带外信息 . 据我所知，REST限制你使用HTTP标头和结果代码 .
（otoh，您可以使用带有REST服务的cookie来发送“标头”类型的带外数据吗？）
不要忽视XML-RPC . 如果您只是在轻量级解决方案之后，那么对于可以在几页文本中定义并以少量代码实现的协议来说，有很多话要说 . XML-RPC已存在多年，但已经过时了一段时间 - 但极简主义的吸引力似乎给了它最近的复兴 .
回答2012年更新（通过第二个赏金）问题，并审查今天的结果（其他答案） .
SOAP，优点和缺点
关于SOAP 1.2，与"REST"相比的优点和缺点......好吧，自2007年you can describe REST Web services with WSDL，并使用SOAP协议......也就是说，如果你的工作稍微努力， all W3C standards of the web services protocol stack can be REST ！
这是一个很好的起点，因为我们可以想象一个暂时避免所有哲学和方法论讨论的场景 . 我们可以在技术上将“SOAP-REST”与类似服务中的“NON-SOAP-REST”进行比较，
SOAP-REST （= "REST-SOAP"）：作为showed by L.Mandel，WSDL2可以描述REST Web服务，如果我们假设示例XML可以包含在SOAP中，则所有实现都将是"SOAP-REST" .
NON-SOAP-REST ：任何不能成为SOAP的REST Web服务......也就是说，众所周知的REST示例的"90%" . 有些人不使用XML（例如典型的AJAX REST使用JSON），有些使用其他XML结构，没有SOAP头或规则 . PS：为了避免非正式性，我们可以在比较中假设REST level 2 .
当然，为了在概念上进行比较，将“NON-REST-SOAP”与“NON-SOAP-REST”进行比较，作为不同的建模方法 . 因此，完成此Web服务分类：
NON-REST-SOAP ：任何不能成为REST的SOAP Web服务......也就是说，众所周知的SOAP示例的"90%" .
NON-REST-NEITHER-SOAP ：是的，"web services modeling"的宇宙包含其他东西（例如XML-RPC） .
REST Session 中的
SOAP
比较可比较的东西：SOAP-REST与NON-SOAP-REST .
PROS
解释一些术语，
Contract 稳定性：适用于各种 Contract （如"written agreements"），
通过使用标准：W3C stack的所有级别都是相互兼容的 . 另一方面，REST不是W3C或ISO标准，也没有关于服务外围设备的规范化细节 . 所以，正如I，@ DaveWoldrich（20票），@ cynicalman（5），@ Exitos（0）之前所说，在需要标准的环境中，你需要SOAP .
通过使用最佳实践：W3C堆栈实现的"verbose aspect"，翻译相关的人/法律/法律协议 .
健壮性：SOAP结构和头文件的安全性 . 通过metada通信（具有完整的XML表达能力）和verification，您可以对任何更改或噪音进行"insurance policy" .
SOAP有"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 .
按人气排序专业人士，
Better tools （约70票）：SOAP目前拥有更好的工具优势，自2007年至2012年，因为它是一个定义明确且被广泛接受的标准 . 见@MarkCidade（27票），@ DaveWoldrich（20），@ JoshM（13），@ TravisHeseman（9） .
Standars compliance （25票）：作为I，@ DaveWoldrich（20票），@ cynicalman（5），@ Exitos（0）之前说过，在需要标准的环境中，你需要SOAP .
Robustness ：SOAP Headers 保险，@ JohnSaunders（8票） .
CONS
SOAP strucuture is more complex （超过300票）：这里的所有答案以及有关"SOAP vs REST"的消息来源都表现出对SOAP冗余和复杂性的某种程度的厌恶 . 这是形式验证要求（见下文）和稳健性（见上文）的自然结果 . "REST NON-SOAP"（和XML-RPC，SOAP originator）可以更简单和非正式 .
The "only XML" restriction is a performance obstacle 使用小型服务时（约50票）：见json.org/xml和this question，或this other one . 这一点由@toluju（41）和其他人展示 .
PS：as JSON is not a IETF standard，但我们可以考虑网络软件社区的事实标准 .
使用SOAP建模服务
现在，我们可以使用NON-SOAP-REST比较添加SOAP-NON-REST，并解释 when is better to use SOAP ：
需要标准和稳定的 Contract （见"PROS"部分） . PS：见typical "B2B need for standards" described by @saille .
需要工具（参见"PROS"部分） . PS：标准，以及正式验证的存在（见下文），是工具自动化的重要问题 .
并行繁重处理（参见下面的"Context/Foundations"部分）：使用更大和/或更慢的进程，无论SOAP的复杂程度如何，可靠性和稳定性都是最佳投资 .
需要更多安全性：当需要超过HTTPS时，您确实需要其他功能来保护，SOAP是更好的选择（see @Bell，32票） . "Sending the message along a path more complicated than request/response or over a transport that does not involve HTTP"，S. Seely . XML是一个核心问题，为XML加密，XML签名和XML规范化提供标准，并且只有使用SOAP，您才能通过广为接受的WS-Security标准将这些机制嵌入到消息中 .
需要更多灵活性（更少限制）：SOAP不需要与URI精确对应;没有限制到HTTP;不需要限制为4个动词 . 正如@TravisHeseman（9票）所说，如果你想要"flexible for an arbitrary number of client technologies and uses"，请使用SOAP .
PS：请记住，XML比JSON（等人）更具普遍性和表现力 .
需要formal verifications：重要的是要了解W3C堆栈使用formal methods，而REST更加非正式 . 您的WSDL（formal language）服务描述是您的Web服务接口的formal specification，而SOAP是一个可靠的协议，它接受所有可能的WSDL处方 .
背景
历史
评估趋势是必要的历史观点 . 对于这个主题，10或15年的视角......
在W3C标准化之前，存在一些无政府状态 . 很难用不同的框架实现可互操作的服务，并且实现公司之间可互操作的东西更加困难，昂贵和耗时 . W3C协议栈标准一直是轻松的，可以实现复杂Web服务集的互操作 .
对于日常工作，比如实施AJAX，SOAP很重要......所以，需要简单的方法需要选择一个新的理论框架......而且大的"Web software players"，如谷歌，亚马逊，雅虎等，选择最好的替代方案，即REST方法 . 在这种情况下，REST概念是以"competing framework"形式出现的，今天（2012年），这种替代方案对于程序员来说是一个de facto standard .
基金会
在并行计算的上下文中，Web服务提供并行子任务;和SOAP一样，协议可确保良好的同步和通信 . 不"any task"：Web服务可归类为
coarse-grained and embarrassing parallelism .
随着任务变得越来越大，它变得不那么重要了“复杂性辩论”，而且变得越来更具相关性的是沟通的稳健性和 Contract 的可靠性 .
这很细致 .
如果您需要让其他系统与您的服务接口，那么很多客户都会对SOAP感到满意，因为您拥有 Contract ，WSDL和SOAP标准的“验证”层 .
对于调用系统的日常系统，我认为在简单的HTML调用时，SOAP会带来很多不必要的开销 .
我正在看同样的事情，我想， they are different tools for different problems .
简单对象访问协议（SOAP）标准是定义消息体系结构和消息格式的XML语言，由Web服务使用，它包含操作的描述 . WSDL是一种基于XML的语言，用于描述Web服务以及如何访问它们 . 将运行在SMTP，HTTP，FTP等上 . 需要中间件支持，定义良好的机制来定义WSDL XSD等服务，WS-Policy SOAP将返回基于XML的数据SOAP提供安全性和可靠性标准
代表性状态转移（RESTful）Web服务 . 它们是第二代Web服务 . RESTful Web服务，通过HTTP进行通信而不是基于SOAP的服务，并且不需要XML消息或WSDL服务API定义 . 对于REST，不需要中间件只需要HTTP支持.WADL Standard，REST可以返回XML，纯文本，JSON，HTML等
许多类型的客户端更容易使用RESTful Web服务，同时使服务器端能够发展和扩展 . 客户可以选择使用服务的部分或全部方面，并将其与其他基于Web的服务混搭 .
REST使用标准HTTP，因此创建客户端，开发API非常简单
REST允许许多不同的数据格式，如XML，纯文本，JSON，HTML，因为SOAP只允许XML .
REST具有更好的性能和可伸缩性 .
休息并且可以缓存而SOAP不能
SOAP没有错误处理的内置错误处理
REST特别适用于PDA和其他移动设备 .
REST是服务易于与现有网站集成 .
SOAP具有一组协议，这些协议提供安全性和可靠性标准，以及与其他符合WS的客户端和服务器的互操作性 . SOAP Web服务（例如JAX-WS）在处理异步处理和调用时很有用 .
对于Complex API，SOAP将更有用 .
我正在看同样的问题 . 在我看来，实际上REST快速简单，适用于轻量级调用和响应，非常适合调试（比将URL引入浏览器并查看响应更好） .
然而，REST似乎倒下的地方在于它不是标准（尽管它由标准组成） . 大多数编程库都有一种检查WSDL的方法，以自动生成使用基于SOAP的服务所需的客户端代码 . 迄今为止，基于REST的Web服务的使用似乎是一种编写接口以匹配可能的调用的更多特殊方法 . 制作手动http请求然后解析响应 . 这本身就很危险 .
SOAP的优点在于，一旦发布了WSDL，那么业务'可以构建他们的逻辑aorund，设置 Contract 对接口的任何更改都将改变wsdl . manouvre没有任何空间 . 您可以根据该WSDL验证所有请求 . 但是，由于WSDL没有正确描述REST服务，因此您没有明确的方式来同意通信接口 .
从商业角度来看，这似乎使得沟通对解释和变革持开放态度，这似乎是一个坏主意 .
这个主题中的顶部“答案”似乎表示SOAP代表面向对象的简单访问协议，但是在Wiki中，O表示对象而不是面向对象 . 它们是不同的东西 .
我知道这篇文章很老，但我想我应该回应一下我自己的发现 .
这是一个很好的问题......我不想让你误入歧途，所以我会像你一样对别人的答案持开放态度 . 对我来说，它实际上取决于开销成本以及API的用途 . 我更喜欢在创建客户端软件时使用Web服务，但我不喜欢SOAP的重量 . 我相信，REST更轻松重量，但我不喜欢从客户的角度来看它几乎同样多 .
我很好奇别人的想法 .
听听this podcast了解一下 . 如果你想在不听的情况下知道答案，那么OK，它的REST . 但我真的建议听 .
我的一般规则是，如果您希望浏览器Web客户端直接连接到服务，那么您应该使用REST . 如果要在后端服务之间传递结构化数据，请使用SOAP .
SOAP有时候很难设置，对于简单的Web客户端和服务器数据交换来说往往是过度的 . 不幸的是，我见过（并从中学到）的大多数简单的编程示例在某种程度上重新强化了这种看法 .
也就是说，当您开始将多个SOAP服务组合在一起作为由数据工作流（思考企业软件）驱动的更大流程的一部分时，SOAP真的很棒 . 这是许多SOAP编程示例无法传达的东西，因为执行某些操作的简单SOAP操作（例如获取股票的价格）通常过于复杂，除非它在提供机器的上下文中呈现可读的API，详细说明具有输入和输出的设置数据格式的特定功能，而这些格式又由更大的进程编写脚本 .
从某种程度上说，这是令人遗憾的，因为它确实给SOAP带来了不好的声誉，因为如果不在最终产品的使用方式的完整背景下展示SOAP，很难展示SOAP的优势 .
SOAP 体现了面向服务的Web服务方法 - 其中方法（或动词）是您与服务交互的主要方式 . REST 采用面向资源的方法，其中对象（或名词）占据中心位置 .
从某种意义上讲，"PHP-universe" PHP对任何高级SOAP的支持都非常糟糕 . 一旦跨越基本需求，您将最终使用类似http://wso2.com/products/web-services-framework/php/的内容，甚至无法启用WS-Security或WS-RM内置支持 .
SOAP信封创建我认为在PHP中创建名称空间很麻烦，xsd：nil，xsd：anytype和旧式SOAP服务使用SOAP编码（上帝知道这有什么不同）在SOAP消息中 .
通过坚持使用REST避免所有这些混乱，自从WWW开始以来，REST并没有什么大不了的 . 我们只是在这篇论文发表时才意识到它展示了我们如何使用HTTP功能来实现RESTFul服务 . HTTP本身就是REST，这并不仅仅意味着使用HTTP使您的服务成为RESTFul .
SOAP忽略了HTTP的核心功能，并将HTTP视为传输协议，因此它在理论上是独立于传输协议的（实际上，如果不是谷歌它现在就听说过SOAP Action Headers 的情况并非如此！） .
随着JSON适应性的增加和HTML5与javascript的成熟，使用JSON的REST已经成为处理服务的最常用方式 . 如果需要，JSON Schema也可以用于企业级解决方案（仍处于早期阶段）以及WADL .
对REST和JSON的PHP支持肯定比现有的内置SOAP支持更好 .
在SOA，WOA，ROA中添加更多BUZZ字
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提供类似的东西，比如字段级加密等 .
一个快速点 - 传输协议和编排;
我使用SOAP over TCP是出于速度，可靠性和安全性的原因，包括编排的机器到机器服务（ESB）和外部服务 . 更改服务定义时，业务流程会从WSDL更改中引发错误，并且它立即显而易见，可以重建/部署 .
不确定你可以用REST做同样的事情 - 我等待纠正或当然！使用REST，更改服务定义 - 在返回400（或其他任何内容）之前一无所知 .
如果您正在寻找不同系统和语言之间的互操作性，我肯定会选择REST . 例如，我在尝试使用.NET和Java之间工作时遇到了很多问题 .
我创建了一个基准，用于查找哪些更快！我看到这个结果：
1000个请求：
REST花了3秒钟
SOAP花了7秒钟
10,000个请求：
REST花了33秒
SOAP耗时69秒
对于1,000,000个请求：
REST花了62秒
SOAP耗时114秒
一个古老的问题，但今天仍然相关....由于企业领域的许多开发人员仍在使用它 .
我的工作涉及设计和开发物联网（物联网）解决方案 . 其中包括为与 Cloud 通信的小型嵌入式设备开发代码 .
很明显，REST现在被广泛接受和使用，并且几乎是网络的事实标准，甚至微软也在整个Azure中都包含REST支持 . 如果我需要依赖SOAP，我就不能做我需要做的事情，因为对于小型嵌入式设备来说太大，太笨重和烦人 .
REST简单，干净，小巧 . 使其成为小型嵌入式设备的理想选择当我与一位向我发送WSDL的Web开发人员合作时，我总是尖叫 . 因为我将不得不开始一个关于为什么这不起作用以及他们为什么要学习REST的教育活动 .