用于 Web 服务的 SOAP 或 REST？ [关闭]
关闭。这个问题是基于意见的。它目前不接受答案。想改进这个问题？更新问题，以便可以通过编辑这篇文章用事实和引用来回答它。 6年前关闭。改进这个问题
REST 是更好的 Web 服务方法还是 SOAP？还是它们是针对不同问题的不同工具？或者这是一个微妙的问题——也就是说，在某些领域中，一个比另一个稍微好一点，等等？
我将特别感谢有关这些概念及其与 PHP 世界以及现代高端 Web 应用程序的关系的信息。
当我在 Hewlett-Packard 工作时，我根据正在开发的原始规范构建了第一批 SOAP 服务器之一，包括代码生成和 WSDL 生成。我不建议将 SOAP 用于任何事情。
首字母缩写词“SOAP”是一个谎言。它不是简单的，它不是面向对象的，它没有定义访问规则。可以说，它是一个协议。这是 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 不同，在 SOAP 中，许多不同的动词可以应用于许多不同的名词（即许多不同的功能）。
对于 REST，四个动词映射到相应的 HTTP 请求，而名词由 URL 标识。这使得状态管理比在 SOAP 中透明得多，在 SOAP 中，它通常不清楚服务器上的状态以及客户端上的状态。
在实践中，尽管其中大部分都消失了，REST 通常只是指在 JSON 中返回结果的简单 HTTP 请求，而 SOAP 是一个更复杂的 API，它通过传递 XML 进行通信。两者都有其优点和缺点，但我发现，根据我的经验，REST 通常是更好的选择，因为您很少需要从 SOAP 获得的全部功能。
快速了解 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
SOAP 目前具有更好的工具的优势，它们将为服务层以及从任何给定的 WSDL 生成客户端生成大量样板代码。
REST 更简单，因此更易于维护，位于 Web 架构的核心，允许更好的协议可见性，并且已被证明可以在 WWW 本身的大小上进行扩展。有些框架可以帮助您构建 REST 服务，例如 Ruby on Rails，有些甚至可以帮助您编写客户端，例如 ADO.NET 数据服务。但在大多数情况下，缺乏工具支持。
null 之类的细微差别。并且生成的样板代码通常只是为了解决 SOAP 本身造成的负担。
从工具的角度来看，SOAP 很有用，因为 WSDL 很容易被工具使用。因此，您可以获得以您喜欢的语言为您生成的 Web 服务客户端。
REST 与 AJAX'y 网页配合得很好。如果您的请求保持简单，您可以直接从 JavaScript 进行服务调用，这非常方便。尽量不要在响应 XML 中包含任何名称空间，我已经看到浏览器对这些名称感到窒息。因此，xsi:type 可能不适合您，没有过于复杂的 XML 模式。
REST 也往往具有更好的性能。生成 REST 响应的代码对 CPU 的要求往往低于 SOAP 框架的要求。而且，如果您将 XML 生成鸭子放在服务器端，您可以有效地将 XML 流式传输到客户端。因此，假设您正在读取数据库游标的行。当您读取一行时，将其格式化为 XML 元素，然后将其直接写出给服务使用者。这样，您不必在开始编写 XML 输出之前收集内存中的所有数据库行 - 您可以同时读取和写入。研究新颖的模板引擎或 XSLT 以使流式处理适用于 REST。
另一方面，SOAP 倾向于由工具生成的服务生成为一个大块，然后才被写入。请注意，这不是绝对的事实，有一些方法可以从 SOAP 中获取流特性，例如使用附件。
我的决策过程如下：如果我希望我的服务易于被消费者使用，并且我编写的消息将是中小型（10MB 或更少），并且我不介意消耗一些额外的 CPU在服务器上循环，我使用 SOAP。如果我需要在 Web 浏览器上为 AJAX 提供服务，或者我需要流式传输，或者我的响应是巨大的，我会选择 REST。
最后，围绕 SOAP 建立了许多出色的标准，例如 WS-Security 和获得有状态的 Web 服务，如果您使用正确的工具，您可以插入这些标准。那种东西真的很重要，可以帮助你满足一些毛茸茸的要求。
我知道这是一个老问题，但我必须发布我的答案——也许有人会觉得它有用。我不敢相信有多少人推荐 REST over 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 有一个。因此，可以从 javascript 中利用 SOAP；只是不如返回 JSON 字符串的 REST 服务好。因此，如果我有一个 Web 服务，我希望它足够复杂，可以灵活地用于任意数量的客户端技术和用途，我会选择 SOAP。
我建议您先使用 REST - 如果您使用 Java，请查看 JAX-RS 和 Jersey 实现。 REST 更简单且易于与多种语言进行互操作。
正如其他人在该线程中所说，SOAP 的问题是当其他 WS-* 规范出现时它的复杂性，如果您误入 WSDL、XSD、SOAP、WS-Addressing 等的错误部分，则会出现无数互操作问题。
判断 REST 与 SOAP 辩论的最佳方法是查看互联网 - 几乎所有网络空间的大玩家，谷歌、亚马逊、ebay、twitter 等 - 都倾向于使用和更喜欢 RESTful API 而不是 SOAP 的。
使用 REST 的另一个不错的方法是，您可以在 Web 应用程序和 REST 前端之间重用大量代码和基础设施。例如，使用 JAX-RS 和隐式视图等框架，渲染资源的 HTML 与 XML 与 JSON 通常非常容易 - 再加上使用 Web 浏览器轻松处理 RESTful 资源
我确信 Don Box 创建 SOAP 是在开玩笑——“看你可以在网络上调用 RPC 方法”，今天当他意识到它已经变成了一个臃肿的网络标准噩梦时，他呻吟着:-)
REST 很好，很简单，在任何地方都可以快速轻松地实现（所以比标准更像是一个“标准”）。使用 REST。
我认为两者都有自己的位置。在我看来：
SOAP：遗留/关键系统和 Web/Web 服务系统之间集成的更好选择，在基础层，WS-* 有意义（安全性、策略等）。
RESTful：在顶层（VIEW，即 javascripts 调用 URI）上使用公共 API 在网站之间进行集成的更好选择。
还没有提到的一件事是 SOAP 信封可以包含标题以及正文部分。这使您可以使用 XML 的完整表达能力来发送和接收带外信息。据我所知，REST 将您限制在 HTTP 标头和结果代码中。
（otoh，您可以使用带有 REST 服务的 cookie 来发送“标头”类型的带外数据吗？）
不要忽视 XML-RPC。如果您只是在追求轻量级解决方案，那么对于可以在几页文本中定义并以最少代码量实现的协议来说，有很多话要说。 XML-RPC 已经存在多年，但已经过时了一段时间——但极简主义的吸引力似乎使它最近得到了某种复兴。
回答 2012 年更新的（通过第二个赏金）问题，并查看今天的结果（其他答案）。
肥皂，优点和缺点
关于 SOAP 1.2，与“REST”相比的优缺点……嗯，从 2007 年开始you can describe REST Web services with WSDL，并且使用 SOAP 协议……也就是说，如果你再努力一点，all W3C standards of the web services protocol stack 可以是 REST ！
这是一个很好的起点，因为我们可以想象一个暂时避免所有哲学和方法论讨论的场景。我们可以在技术上将“SOAP-REST”与类似服务中的“NON-SOAP-REST”进行比较，
SOAP-REST (="REST-SOAP")：如 L.Mandel 所示，WSDL2 可以描述 REST Web 服务，如果我们假设示例 XML 可以封装在 SOAP 中，那么所有的实现都将是“SOAP-REST” .
NON-SOAP-REST：任何不能是 SOAP 的 REST Web 服务……也就是说，“90%”的众所周知的 REST 示例。有些不使用 XML（例如，典型的 AJAX REST 使用 JSON 代替），有些使用另一种 XML 结构，没有 SOAP 标头或规则。 PS：为了避免非正式性，我们可以在比较中假设 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 票），@cynicalman（5），@Exitos（0）之前所说，在需要标准的情况下，你需要 SOAP。通过使用最佳实践：W3C 堆栈实现的“详细方面”翻译相关的人类/法律/司法协议。
通过使用标准：W3C 堆栈的所有级别都是相互兼容的。另一方面，REST 不是 W3C 或 ISO 标准，并且没有关于服务外围设备的规范化细节。所以，正如我，@DaveWoldrich（20 票），@cynicalman（5），@Exitos（0）之前所说，在需要标准的情况下，你需要 SOAP。
通过使用最佳实践：W3C 堆栈实现的“详细方面”翻译相关的人类/法律/司法协议。
健壮性：SOAP 结构和标头的安全性。通过元数据通信（具有 XML 的完整表达能力）和验证，您拥有针对任何更改或噪音的“保险政策”。 SOAP 具有“处理通信故障的事务可靠性 (...)。SOAP 对重试逻辑有更多的控制，因此可以提供更多的端到端可靠性和服务保证”，E. Terman。
按受欢迎程度对专业人士进行排序，
更好的工具（约 70 票）：自 2007 年到 2012 年，SOAP 目前具有更好工具的优势，因为它是一个定义明确且被广泛接受的标准。参见@MarkCidade（27 票）、@DaveWoldrich（20）、@JoshM（13）、@TravisHeseman（9）。
标准合规性（25 票）：正如我、@DaveWoldrich（20 票）、@cynicalman（5）、@Exitos（0）之前所说，在需要标准的情况下，您需要 SOAP。
稳健性：SOAP 标头的保险，@JohnSaunders（8 票）。
缺点
SOAP 结构更复杂（超过 300 票）：这里的所有答案，以及有关“SOAP 与 REST”的来源，都表现出对 SOAP 的冗余和复杂性的某种程度的厌恶。这是形式验证（见下文）和稳健性（见上文）要求的自然结果。 “REST NON-SOAP”（以及 XML-RPC，SOAP 的发起者）可以更加简单和非正式。
使用小型服务（约 50 票）时，“仅 XML”限制是性能障碍：请参阅 json.org/xml 和这个问题，或其他问题。这一点由@toluju(41) 和其他人展示。 PS：因为 JSON 不是 IETF 标准，但我们可以考虑成为 Web 软件社区事实上的标准。
使用 SOAP 建模服务
现在，我们可以添加 SOAP-NON-REST 和 NON-SOAP-REST 比较，并解释什么时候使用 SOAP 更好：
需要标准和稳定的合约（参见“PROS”部分）。 PS：请参阅@saille 描述的典型“B2B 需要标准”。
需要工具（参见“PROS”部分）。 PS：标准和形式验证的存在（见下文）是工具自动化的重要问题。
并行繁重的处理（参见下面的“上下文/基础”部分）：对于更大和/或更慢的进程，无论 SOAP 稍微复杂一点，可靠性和稳定性都是最好的投资。
需要更高的安全性：当需要的不仅仅是 HTTPS，并且您确实需要额外的保护功能时，SOAP 是更好的选择（参见@Bell，32 票）。 “沿着比请求/响应更复杂的路径或通过不涉及 HTTP 的传输方式发送消息”，S. Seely。 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 年的角度来看……
在 W3C 标准化之前，存在一些无政府状态。很难实现具有不同框架的可互操作服务，并且实现公司之间可互操作的东西更加困难、昂贵和耗时。 W3C 堆栈标准一直是一组复杂的 Web 服务互操作的一个轻量级标准。
对于日常任务，比如实现 AJAX，SOAP 很重......所以，需要简单的方法需要选择一个新的理论框架......还有大的“网络软件玩家”，如谷歌、亚马逊、 Yahoo 等人选择了最佳替代方案，即 REST 方法。在这种情况下，REST 概念作为“竞争框架”出现，而在今天（2012 年），这种替代方案是程序员的de facto standard。
基础
在并行计算的上下文中，Web 服务提供并行子任务；和协议，如 SOAP，确保良好的同步和通信。不是“任何任务”：网络服务可以归类为
coarse-grained and embarrassing parallelism。
随着任务变得越来越大，“复杂性辩论”变得不那么重要，而与通信的稳健性和合约的稳固性变得更加相关。
它很微妙。
如果您需要与您的服务有其他系统接口，那么由于您对合同、WSDL 和 SOAP 标准的“验证”层，很多客户会更喜欢 SOAP。
对于调用系统的日常系统，我认为当一个简单的 HTML 调用就可以时，SOAP 是很多不必要的开销。
我正在看同样的东西，我认为它们是针对不同问题的不同工具。
简单对象访问协议 (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 标准，REST 可以返回 XML、纯文本、JSON、HTML 等
许多类型的客户端更容易使用 RESTful Web 服务，同时使服务器端能够发展和扩展。客户可以选择使用服务的部分或全部方面，并将其与其他基于 Web 的服务混合。
REST 使用标准 HTTP，因此创建客户端和开发 API 更简单 REST 允许许多不同的数据格式，如 XML、纯文本、JSON、HTML，而 SOAP 只允许 XML。 REST 具有更好的性能和可扩展性。 REST 可以被缓存而 SOAP 不能 SOAP 没有的内置错误处理 没有错误处理 REST 对 PDA 和其他移动设备特别有用。
REST 是易于与现有网站集成的服务。
SOAP 具有一组协议，这些协议提供安全性和可靠性等标准，并与其他符合 WS 的客户端和服务器互操作。 SOAP Web 服务（例如 JAX-WS）在处理异步处理和调用方面很有用。
对于复杂 API 的 SOAP 会更有用。
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 添加任何重要功能存在一些争论。
在编写 Web 服务之前，我建议学习 HTTP。奇怪的是，您的要求可以使用规范中已经定义的功能来实现，因此不需要其他协议。
我正在研究同样的问题。在我看来，实际上 REST 快速、简单，适用于轻量级调用和响应，并且非常适合调试（这可能比将 URL 输入浏览器并查看响应更好）。
然而，REST 似乎失败的地方在于它不是一个标准（尽管它是由标准组成的）。大多数编程库都有一种检查 WSDL 的方法，以自动生成使用基于 SOAP 的服务所需的客户端代码。到目前为止，使用基于 REST 的 Web 服务似乎是一种更特别的方法，可以编写一个接口来匹配可能的调用。发出手动 http 请求，然后解析响应。这本身就很危险。
SOAP 的美妙之处在于，一旦发布了 WSDL，那么业务就可以构建他们的逻辑环绕，即设置合同对接口的任何更改都会更改 wsdl。没有任何回旋余地。您可以针对该 WSDL 验证所有请求。但是，由于 WSDL 没有正确描述 REST 服务，因此您无法就通信接口达成一致意见。
从商业角度来看，这似乎确实让沟通变得容易被解释和改变，这似乎是个坏主意。
该线程中的顶部“答案”似乎说 SOAP 代表简单的面向对象访问协议，但是查看 wiki 中的 O 表示对象不是面向对象的。它们是不同的东西。
我知道这篇文章已经很老了，但我认为我应该用我自己的发现来回应。
这是一个很好的问题......我不想让你误入歧途，所以我和你一样愿意接受其他人的答案。对我来说，这实际上归结为开销成本和 API 的用途。在创建客户端软件时，我更喜欢使用 Web 服务，但是我不喜欢 SOAP 的重量。我相信 REST 的重量更轻，但从客户的角度来看，我不太喜欢使用它。
我很好奇别人怎么想。
我的一般规则是，如果您希望浏览器 Web 客户端直接连接到服务，那么您可能应该使用 REST。如果要在后端服务之间传递结构化数据，请使用 SOAP。
有时设置 SOAP 确实很痛苦，而且对于简单的 Web 客户端和服务器数据交换而言，它通常是多余的。不幸的是，我见过（并从中学到的）大多数简单的编程示例都在某种程度上强化了这种看法。
也就是说，当您开始将多个 SOAP 服务组合在一起作为由数据工作流（想想企业软件）驱动的更大流程的一部分时，SOAP 真的会大放异彩。这是许多 SOAP 编程示例未能传达的内容，因为用于执行某些操作（例如获取股票价格）的简单 SOAP 操作通常对于它本身所做的操作来说过于复杂，除非它在提供机器的上下文中呈现可读的 API 详细说明了具有用于输入和输出的设定数据格式的特定功能，而这些数据格式又由更大的进程编写脚本。
这在某种程度上是可悲的，因为它确实给 SOAP 带来了坏名声，因为如果不在最终产品的使用方式的完整上下文中展示 SOAP 的优势，就很难展示它。
SOAP 体现了一种面向服务的 Web 服务方法——其中方法（或动词）是您与服务交互的主要方式。 REST 采用面向资源的方法，其中对象（或名词）占据中心位置。
从某种意义上说，“PHP 世界”对任何高级 SOAP 的 PHP 支持都非常耗时。一旦满足基本需求，您最终将使用 http://wso2.com/products/web-services-framework/php/ 之类的东西，甚至启用 WS-Security 或 WS-RM 没有内置支持。
SOAP 信封创建我觉得在 PHP 中很混乱，它创建名称空间的方式、xsd:nil、xsd:anytype 和老式的肥皂服务在 SOAP 消息中使用 SOAP 编码（天知道有什么不同）。
通过坚持使用 REST 来避免所有这些混乱，自 WWW 开始以来，我们一直在使用 REST 并没有什么大不了的。直到这篇 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 支持更好。
在此处添加更多 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 规范，这是一个很好的规范，如果有人考虑企业 JSON 适配，肯定需要为 JSON 提供一些类似的东西，比如字段级加密等。
一个快点——传输协议和编排；
出于速度、可靠性和安全性的原因，我使用 SOAP over TCP，包括编排的机器对机器服务 (ESB) 和外部服务。更改服务定义，编排会从 WSDL 更改中引发错误，并且其立即显而易见并且可以重新构建/部署。
不确定您是否可以对 REST 做同样的事情 - 我正在等待更正或课程！使用 REST，更改服务定义 - 在它返回 400（或其他）之前，什么都不知道。
如果您正在寻找不同系统和语言之间的互操作性，我肯定会选择 REST。例如，我在尝试让 SOAP 在 .NET 和 Java 之间工作时遇到了很多问题。
我创建了一个基准来查找其中哪些更快！我看到了这个结果：
对于 1000 个请求：
REST 耗时 3 秒
SOAP 耗时 7 秒
10,000 个请求：
REST 耗时 33 秒
SOAP 耗时 69 秒
对于 1,000,000 个请求：
REST 耗时 62 秒
SOAP 耗时 114 秒
一个古老的问题，但今天仍然相关......由于企业领域的许多开发人员仍在使用它。
我的工作涉及设计和开发 IoT（物联网）解决方案。其中包括为与云通信的小型嵌入式设备开发代码。
很明显，REST 现在已被广泛接受和使用，并且几乎是 Web 的事实上的标准，甚至 Microsoft 在整个 Azure 中都包含 REST 支持。如果我需要依赖 SOAP，我将无法做我需要做的事情，因为它对于小型嵌入式设备来说太大、笨重且烦人。
REST 简单、干净、小巧。使其成为小型嵌入式设备的理想选择。当我与向我发送 WSDL 的 Web 开发人员一起工作时，我总是尖叫。因为我将不得不开始一场关于为什么这不起作用以及为什么他们必须学习 REST 的教育活动。
1.根据我的经验。我想说 REST 让您可以选择访问已经构建的 URL。例如-> google 中的单词搜索。该 URL 可以用作 REST 的 Web 服务。在 SOAP 中，您可以创建自己的 Web 服务并通过 SOAP 客户端访问它。
REST 支持文本、JSON、XML 格式。因此，对于两个应用程序之间的通信更加通用。而 SOAP 只支持 XML 格式的消息通信。
关注公众号
不定期副业成功案例分享
