比较和对比 REST 和 SOAP Web 服务？ [复制]

Posted 2023-02-15

【中文标题】比较和对比 REST 和 SOAP Web 服务？ [复制]

【英文标题】：Compare and contrast REST and SOAP web services? [duplicate]

【发布时间】：2012-06-14 02:35:09

【问题描述】：

我目前发现类似的情况是两者都使用互联网协议 (HTTP) 在消费者和提供者之间交换数据。

区别在于：

SOAP 是一种基于 XML 的消息协议，而 REST 是一种架构风格 SOAP 使用 WSDL 在消费者和提供者之间进行通信，而 REST 仅使用 XML 或 JSON 来发送和接收数据 SOAP 通过调用 RPC 方法调用服务，REST 只是简单地通过 URL 路径调用服务 SOAP 不返回人类可读的结果，而 REST 结果可以通过纯 XML 或 JSON 读取 SOAP 不只是通过 HTTP，它还使用其他协议，例如 SMTP、FTP 等，REST 仅通过 HTTP

这就是我所知道的它们之间的区别。谁能纠正我并添加更多内容。

【问题讨论】：

它们是无法比较的，至少因为 SOAP 是一种协议，而 REST 是一个根本没有定义规范的概念。没有什么能阻止人们编写与 REST 兼容的 SOAP Web 服务。

(1) "SOAP 是一种基于 XML 的消息协议" (2) "SOAP 不返回人类可读的结果" -- - 结论：XML 不是人类可读的。但显然……公平地说其中一个前提一定是错误的？

【参考方案1】：

SOAP 使用 WSDL 来进行消费者和提供者之间的通信，而 REST 只是使用 XML 或 JSON 来发送和接收数据

WSDL 定义了客户端和服务之间的契约，并且本质上是静态的。如果 REST 合同有些复杂，并且由 HTTP、URI、媒体格式和应用程序特定协调协议定义。与 WSDL 不同，它是高度动态的。

SOAP 不返回人类可读的结果，而 REST 结果可以通过纯 XML 或 JSON 读取

这不是真的。纯 XML 或 JSON 根本不是 RESTful。它们都没有定义任何反对 REST 的控件（即链接和链接关系、方法信息、编码信息等），因为消息必须是自包含的并协调代理/客户端和服务之间的交互。

有了链接+语义链接关系，客户端应该能够确定下一个交互步骤是什么，并遵循这些链接并继续与服务通信。

消息不必是人类可读的，可以使用神秘的格式并构建完全有效的 REST 应用程序。消息是否可读并不重要。

因此，纯 XML(application/xml) 或 JSON(application/json) 格式不足以构建 REST 应用程序。使用这些通用媒体类型的子集总是合理的，它们具有强烈的语义含义并提供足够的控制信息（链接等）来协调客户端和服务器之间的交互。

有关控制信息的更多详细信息，我强烈建议您访问 阅读：http://www.amundsen.com/hypermedia/hfactor/ 网页链接：https://www.rfc-editor.org/rfc/rfc5988 已注册的链接关系： http://www.iana.org/assignments/link-relations/link-relations.xml

REST 仅通过 HTTP

不正确，HTTP 使用最广泛，当我们谈论 REST Web 服务时，我们只是假设 HTTP。 HTTP 定义了接口及其方法（GET、POST、PUT、DELETE、PATCH 等）和可以统一用于与资源交互的各种标头。这种一致性也可以通过其他协议实现。

附： 非常简单但非常有趣的 REST 解释：http://www.looah.com/source/view/2284

【讨论】：

+1 最后一个链接（“我如何向我妻子解释 REST”）

【参考方案2】：

在日常实用编程术语中，最大的区别在于，使用 SOAP，您使用的是静态和强定义的数据交换格式，而相比之下，REST 和 JSON 数据交换格式非常松散。例如，使用 SOAP，您可以验证交换的数据是否与 XSD 模式匹配。因此，XSD 充当了客户端和服务器如何理解所交换数据的结构的“合同”。

JSON 数据通常不会根据强定义的格式传递（除非您使用支持它的框架.. 例如 http://msdn.microsoft.com/en-us/library/jj870778.aspx 或实现 json-schema）。

事实上，一些人（很多/大多数人）会争辩说，JSON 的“动态”秘诀违背了通过数据合约约束它的哲学/文化 (Should JSON RESTful web services use data contract)

习惯于使用动态松散类型语言工作的人们往往更喜欢 JSON 的松散性，而来自强类型语言的开发人员更喜欢 XML。

http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide

【讨论】：

protobuf 的类型比 XML 强得多！

来自documentation：“..您使用协议缓冲区编译器 protoc 编译 [数据] 以生成 C++、Java 或 Python 代码”- 似乎非常有限。直接的 JSON 和 SOAP 不会受到这些限制，因为重点是语言中立。

@fread2281 protobuf 的类型不是更强（那不是真的）。这是一个高性能的有线协议，需要编译后的代码来支持最新的格式（@Michael.M），这实际上与 SOAP 的限制没有什么不同，在 SOAP 的限制中，您必须在每一端部署 WSDL 和代码来应对采用最新格式。

【参考方案3】：

SOAP 带来了它自己的协议，并专注于将应用程序逻辑（而不是数据）作为服务公开。 SOAP 公开操作。 SOAP 专注于访问命名操作，每个操作通过不同的接口实现一些业务逻辑。

尽管 SOAP 通常被称为“Web 服务”，但这是用词不当。 SOAP 与 Web 几乎没有任何关系。 REST 提供基于 URI 和 HTTP 的真正“Web 服务”。

作为说明，这里有几个电话和带有评论的适当主页。

getUser(User);

这是访问资源（数据）时的休息操作。

switchCategory(User, OldCategory, NewCategory)

REST 允许许多不同的数据格式，而 SOAP 只允许 XML。虽然这似乎增加了 REST 的复杂性，因为您需要处理多种格式，但根据我的经验，它实际上是非常有益的。 JSON 通常更适合数据并且解析速度更快。 REST 支持 JSON，因此可以更好地支持浏览器客户端。

【讨论】：

有趣，这个答案正是 this 2010 年 1 月的博文所说的……几乎是逐字逐句

"(not data)" = FALSE - SOAP Web 服务中的 WSDL 对返回的数据 in/out 提供了非常丰富和清晰的描述，以便数据可以根据XSD“合同”。这就是它在 .Net/WCF 中被称为“DataContract”的全部原因

("SOAP 只允许 XML") = 这并不意味着您不能保持 XML 标记非常简洁并嵌入任何其他格式，包括 JSON 或 base64 编码数据。如果您认为必须将 SOAP 数据包装在标记 (XML) 中，那么反驳 JSON 也需要它的标记包装才能从 A 点到 B 点很简单。使用 SOAP Web 服务 javascript 很简单。

"REST 允许 更好 支持浏览器客户端，因为它支持 JSON" = FALSE - 旧版浏览器不支持原生 JSON 解析 (***.com/questions/891299/…)自 AJAX 时代以来，就可以通过 JavaScript 请求进行 SOAP 调用。 jQuery SOAP 是一个库示例，它使得从可以运行 jQuery JavaScript 代码的浏览器调用 SOAP 服务变得非常简单。你能指定另一种“更好”的方式吗？？