REST与SOAP
无抓取抓取API提供特定于任务的HTTP接口，返回结构化的公共Web数据，供应用工作流使用。
简而言之
- REST是一种架构风格；SOAP是一种消息传递协议。 它们在Web服务设计中重叠，但定义了不同的层次和约束。
- REST通常直接使用HTTP语义。 SOAP携带一个XML信封，并可以使用HTTP或其他绑定。
- SOAP偏向于正式的消息合同和扩展标准。 REST偏向于统一接口、资源表示和Web基础设施。
- 安全需求可能会改变决策。 消息级签名和中介与连接级保护和应用授权不同。
- 现有合同往往超过新建项目的偏好。 迁移价值必须超过改变消费者、工具、治理和合规证据的成本。
REST和SOAP不是相同类别
REST是一种架构风格，受限于分布式超媒体系统中的组件和交互。SOAP是一种协议和XML消息传递框架，具有信封、可选头、主体、故障模型、处理角色和绑定。REST API可以使用XML，SOAP服务可以使用HTTP，因此“JSON与XML”是一个不完整的比较。
决定性的问题是系统需要哪种合同和操作模型。REST使用已识别的资源、表示和统一接口，能够利用HTTP方法、状态、缓存和中介。SOAP标准化消息容器和可扩展性模型，能够支持正式的服务描述和消息级功能。W3C维护 SOAP规范系列,而REST的约束源于描述Web的架构工作。
交互在网络上的差异
REST与SOAP：架构、消息传递和权衡在其处理路径明确时更容易操作。以下阶段显示可以收集证据的地方，以及政策可以改变结果的地方。
典型的REST交互
客户端通过URI访问资源，通过接口语义表达意图，发送元数据和可能的表示，并接收状态和表示。通用HTTP组件可以理解方法、缓存、验证、重定向和内容元数据。
典型的SOAP交互
客户端发送一个XML信封，其主体携带操作消息，其头可能携带定义的扩展。接收者遵循SOAP处理规则并返回另一个信封，可能包含故障。HTTP细节取决于选定的SOAP绑定。
合同和工具
REST合同从散文到机器可读的API描述和媒体类型定义。SOAP生态系统通常使用WSDL和XML模式进行操作、类型、绑定和地址，使生成的存根和基于政策的企业工具成为可能。
REST与SOAP比较矩阵
围绕REST与SOAP：架构、消息传递和权衡的词汇涵盖架构、数据和操作。该表将这些职责分开，以便设计评审能够提出正确的问题。
| 维度 | REST | SOAP |
|---|---|---|
| 性质 | 具有必需和可选约束的架构风格。 | 基于XML的消息传递协议和处理框架。 |
| 主要抽象 | 资源及其表示。 | 消息和应用定义的操作。 |
| 通用数据格式 | 通常为JSON，但可以使用任何合适的表示。 | XML信封与XML应用内容。 |
| 传输 | 通常为HTTP，与其语义紧密对齐。 | 可以绑定到HTTP和其他底层协议。 |
| 缓存 | 直接使用HTTP缓存元数据是自然的选择。 | 通过绑定或应用设计可能实现，但不是中心消息抽象。 |
| 正式扩展 | 通常由HTTP、媒体类型和应用标准组成。 | 存在广泛的WS-*家族，用于安全性、寻址、策略和相关问题。 |
当每种风格更适合时
REST与SOAP的实际案例：架构、消息和权衡，首先要考虑系统必须执行的工作。这些示例展示了该需求如何改变接口或网络决策。
Web原生资源API的REST
可缓存的读取、广泛的客户端访问和简单的HTTP操作有利于REST风格设计。
SOAP用于强制的企业合同
现有的WSDL、XML Schema、消息安全或行业配置文件可以使SOAP成为互操作的选择。
公共开发者平台的REST
简单的检查和成熟的HTTP网关降低了各种消费者的入门成本。
带有中介的SOAP消息路径
头角色和消息级处理适合基础设施参与传输的工作流。
一个实用的选择框架
在比较开发者 ergonomics 之前列出不可谈判的需求。集成是否需要特定的行业配置文件、签名消息部分、正式的模式验证、中介、异步消息、HTTP缓存、浏览器兼容性或许多独立的公共消费者？需求常常在主观偏好之前就消除了某一种方法。
评估周围的组织。SOAP 可能适合具有稳定WSDL治理、生成客户端、证书操作和既定合规控制的环境。REST 可能适合那些已经操作HTTP网关、资源API、标准可观测性和Web缓存的团队。在没有能力操作的情况下选择一种风格只是将复杂性转移到事件中。
正确保护两种风格。 HTTP语义规范 指导REST在HTTP上的交互，而SOAP扩展可以添加消息级安全性。两者都无法消除对传输保护、身份验证、授权、输入限制、机密管理、审计能力和域验证的需求。
REST与SOAP神话
- SOAP始终更安全。 SOAP具有消息安全标准，但安全性取决于正确的政策、库、密钥管理、传输、授权和操作。
- REST仅支持JSON。 REST适用于符合资源的媒体类型和语义的表示，包括XML、HTML、图像和二进制格式。
- SOAP无法使用HTTP。 HTTP是常见的SOAP绑定；区别在于SOAP在绑定之上定义了自己的消息框架。
- REST没有合同。 REST API可以具有精确的模式、媒体类型、文档和机器可读描述，即使REST不需要WSDL。
- 用REST替换SOAP消除复杂性。 在数据格式变化后，相同的业务规则、身份、事务、治理和兼容性需求仍然存在。
在SOAP和REST之间迁移
库存操作、模式、故障代码、安全头、策略断言、消费者、体量和合规证据。映射业务能力而不是将每个SOAP操作翻译为动词形状的REST路径。为新边界定义稳定的资源、状态转换、表示和错误含义。
一个外观可以减少消费者的干扰。REST外观可能调用一个已建立的SOAP服务，或者SOAP外观可能在新内部演进时保护遗留客户端。外观必须保留授权、关联性、幂等性和错误语义；浅层格式转换可能隐藏关键结果。
从消费者的角度运行合同测试。比较成功结果、验证失败、授权决定、重复提交、大负载、空或可选字段、字符编码、时间处理和审计跟踪。迁移有界消费者组，直到新的证据完成时保持旧的边界。
REST与SOAP：架构、消息和权衡审查清单
使用这些检查将REST与SOAP：架构、消息和权衡定义转化为实现证据，开发者、运营商或审核员可以重复该过程。
- 重述边界。 对于REST与SOAP：架构、消息和权衡，识别调用者、提供者、路径和标志完整结果的确切事件。
- 验证中心声明。 用实现及其文档确认此声明：REST是一种架构风格；SOAP是一种消息协议。它们在Web服务设计中重叠，但定义不同的层和约束。
- 追踪机制。 观察典型的REST交互、典型的SOAP交互、合同和工具，并记录每个阶段哪个组件拥有。
- 检查最近的区别。 记录为什么自然在这个系统中意味着“带有必需和可选约束的架构风格”。
- 测试一个代表性的用例。 使用REST为Web原生资源API提供具有现实数据、位置、体量和权限边界的服务。
- 防止已知错误。 审查“SOAP总是更安全。”并添加一个接受检查以捕获它。
- 限制工作负载。 为REST与SOAP设定适当的主题限制：架构、消息和权衡，包括适用的有效负载、并发、执行时间和存储输出。
- 记录决定。 解释为什么REST与SOAP：架构、消息和权衡符合这个边界，并列出可以在后期证明采取不同方法的证据。
结论
REST与SOAP：架构、消息和权衡应该描述设计中可测试的部分，而不是作为邻近行为的宽泛标签。审查应该保留这一核心决定：REST是一种架构风格；SOAP是一种消息协议。它们在Web服务设计中重叠，但定义了不同的层次和约束。它还应该防止“SOAP总是更安全。”并保持REST与SOAP：架构、消息和权衡在文档中规定的接口或网络策略内的访问。
准备构建您的Web数据工作流程吗？
将测量的REST与SOAP：架构、消息和权衡获取或集成步骤连接到上述描述的验证和存储实践。
今天注册并获得 $5的免费信用 — 不需要信用卡.
领取您的$5信用→常见问题解答
REST比SOAP好吗？
REST并不总是比SOAP更好。REST通常适合Web本地资源API和广泛的开发者访问，而SOAP则适合正式的企业合同、消息级标准和已建立的行业档案。
SOAP过时了吗？
没有。SOAP已经成熟，仍然存在于长期的企业和行业系统中。在简单的公共Web API中使用较少，但现有的合同和安全配置文件可能使其成为实际选择。
REST可以使用XML吗？
可以。REST不要求使用JSON。REST API可以在媒体类型和语义被记录时交换XML或其他表示形式。
一个系统可以同时支持REST和SOAP吗？
可以。一个系统可以在共享应用服务上暴露单独的REST和SOAP边界，或者在迁移期间使用外观模式。每个边界应保留清晰的合同、授权和错误含义。