API 是应用程序编程接口（Application Programming Interface）的缩写。API 规定了不同的软件组件应如何以编程方式进行交互和通信。
最常见的 API 类型就是 Web API。网络应用（包括网站）向 Web API 或网络服务发送请求，要求向用户显示数据。举个例子一个网站会根据你的搜索条件，返回航班、酒店或租车的最优惠 信息。网站不会从它的数据库中检索这些数据，而是通过向专门提供航班、酒店等服务的 API 发送请求来获取数据的。Web API 就是使用 HTTP 协议传输数据的 API。
目前最流行的两种网络 API 规范是 REST 和 SOAP。
关于哪种架构风格最适合构建 API，目前还存在争议。它们虽然都是规范，但却不能把它们相提并论，有一个微妙的区别在于，REST 是一种 API 架构风格，而 SOAP 则是一种访问网络服务的协议。它们看似相互竞争，但两者都有各自的使用场景。
本文将探讨这两种标准之间的差异，以及两种协议该如何选择。
REST 和 SOAP 的异同
REST 和 SOAP 之间的共同点是什么，为什么它们经常被拿来比较？
REST 和 SOAP 都是规范，为用户如何访问网络服务、与网络服务交互以及它们所暴露的功能提供了标准。如前文所述，REST 是一种 API 架构风格，而 SOAP 是一种数据传输协议。
- REST 作为一种架构风格，对 Web API 的设计有一定的限制。REST 标准要求被视为 "RESTful "的 Web API 必须遵守 REST 约束。这些约束包括客户端与 API 服务器分离、无状态和可缓存性等等。
- SOAP 作为 Web API 协议，是一种数据传输的标准，它规定了消息的：
- 格式
- 通信协议
- 处理方式。与 SOAP 不同，REST 并不规定如何处理 API 信息
由于 SOAP 只是一种 Web API 协议，因此 REST API 可以使用 SOAP 协议作为数据传输的标准。不过，REST 和 SOAP 是不同的标准，一般不能混用。
虽然一个是架构，一个是协议，但两者都为 API 消息格式提供了标准。REST 和 SOAP 的信息格式可由人类和机器读取。对于 REST 而言，JSON 是一种轻量级数据交换格式，与浏览器高度兼容。对于 SOAP 而言，XML 是一种可扩展的标记语言，允许自定义描述性标记，便于阅读。稍后将详细讨论这些数据格式。
在 REST 之前的 SOAP
SOAP 出现在 REST 之前。REST 的设计旨在解决 SOAP 的一些问题。REST 的目标是轻量级、与浏览器高度兼容、将客户端与服务器分离并提供缓存功能。
那么，如果 REST 出现在 SOAP 之后，并且 REST 解决了 SOAP 的问题，为什么 SOAP 还存在呢？
这是因为虽然 REST 比 SOAP 有明显的优势，而且在某些方面来说，REST 的目的就是要取代 SOAP，但 SOAP 也依然有它的用武之处。例如 SOAP 适合需要消息级安全性的企业级应用。
什么是 REST API？
REST 是"表征性状态传输"（Representational State Transfer）的缩写，是一种特定的 API 构建风格，通过这种风格进行约束的 API 被认为是 RESTful AP I。RESTful API 必须满足以下要求：
- 统一的接口
- 无状态
- 可缓存
- 客户端与服务器分离
- 分层系统
- 按需编码
REST API 是使用 HTTP 协议的 Web API，其中客户端向 API 服务器发送 HTTP 数据请求，然后服务端将带有编码数据的 HTTP 响应回客户端。
客户端使用 "资源 "访问和操作 REST API 公开的数据。资源代表不同的 API 功能，并通过资源 URL 对其进行访问。可以将资源视为 API 返回的数据对象。在发送请求时，你会向资源传递一个与 CRUD（创建、读取、更新和删除）操作相对应的方法。将方法视为对资源采取的 "操作"，例如创建、更新或删除资源。
例如，众所周知的 Swagger Petstore API 由多个资源组成。这些资源包括宠物、商店和用户。所有资源都与宠物店这一主题有关，每个资源都代表了你可以创建、操作或删除的不同数据对象。
要请求一个资源，你需要向该资源的唯一 URL 发送 HTTP 请求，并指定要对该资源采取的操作（方法）。示例操作包括创建、更新、查询或删除资源（分别为 POST、PUT、GET 和 DEL）。
REST API 的优点
前后端分离
前后端分离具有以下优点：
- 所有组件的可迁移性。 由于 REST 架构是"多层次的"，所以服务器组件具有可迁移性。REST API 可在多个平台上使用，这可以在开发过程中轻松进行测试。
- 通过限制架构层之间的交互（多层次架构）， 提高了可扩展性。这种限制简化了服务器组件。这种架构还提高了在服务器之间迁移数据的灵活性，并且可以迅速推出新的更改。
- 更易集成。 REST使开发人员能够更多地关注用户界面、功能和业务规则，而不是由API服务器处理的服务器组件和数据管理。
支持 JSON 消息格式
REST 使用 JSON 作为数据格式有几个优点：
- 浏览器兼容性：JSON 作为一种数据格式，与浏览器非常兼容，对浏览器更友好。
- 占用带宽少：JSON 是一种极其轻量级且易于解析的数据格式。XML 有效载荷（就 SOAP 而言）比 JSON 大。较大的有效载荷需要更多带宽。编写 XML SOAP 请求所需的代码量也会增加信息的大小。
信息格式的灵活性
除了 JSON 之外，REST 还提供更多信息格式，如 HTML、纯文本、XML、YAML 等。消息格式的灵活性使 REST 更适用于公共 API。
什么是 SOAP？
XML 允许使用自定义的描述性标签来存储和共享信息，这与 HTML 使用的预定义标签不同。XML 的标准化特性使其能够在不同平台和系统间轻松迁移。作为一种消息格式，XML 提供了很高的灵活性，用户可以根据需求定义 XML 模式，以确保 XML 消息的结构满足特定要求。
在数据访问和操作方式上，SOAP API 与 REST API 有所区别。REST API 通过资源 URL 来访问数据，而 SOAP API 则是通过调用特定的 API 函数来操作数据。
与 REST 不同，SOAP 请求中并不直接包含 CRUD（创建、读取、更新、删除）操作。相反，这些操作是通过调用不同的函数来实现的。例如，在 REST API 中，通常只需一个 URL 端点，通过发送 POST 或 PUT 请求即可完成资源的创建或更新。而在 SOAP 中，创建或更新数据对象需要分别调用处理这些特定操作的独立函数。
XML 消息主要通过 HTTP 或 HTTPS 协议进行传输。但值得注意的是，SOAP API 还支持其他传输协议，如传输控制协议（TCP）、简单邮件传输协议（SMTP）和用户数据报协议（UDP）。相比之下，REST API 则仅限于使用 HTTP 协议。
SOAP 的优势
更强的安全性
SOAP 非常适合注重安全的网络服务，因为它使用 WS-Security（以及 SSL）和内置 ACID 合规性。REST 则不具备这些功能。WS-Security 是关于对 SOAP XML 消息进行签名和加密的规范。每个 SOAP 请求的标题块都包含完成请求所需的安全信息。ACID 合规性是一套保护数据库完整性的标准。许多企业级和金融交易应用程序都需要 ACID 合规性。
灵活的传输渠道
SOAP 支持多种通信协议。REST 仅支持 HTTP。使用 SOAP，你可以使用 HTTP、HTTPS、用户数据协议（UDP）、传输控制协议（TCP）或简单邮件传输协议（SMTP）。
REST 剖析
REST API 由以下部分组成：
- 请求方法： 希望对资源执行的 CRUD 操作。在本例中，HTTP 方法 POST 表示希望创建某个内容。
- 端点： 资源的特定端点（资源 URL）。在本例中，端点是 petstore.swagger.io/v2/pet。资源是 API 返回的数据对象，可使用端点进行定位。
- 请求头： 指定信息格式，本例中为 JSON 格式。您可以在请求头中传递授权租户（如 API 密钥）。
- 请求体： 包含一个 JSON 对象，其中包含新资源的属性。在本例中，请求体包含新宠物的详细信息。请求体与参数类似，只是它们是包含多个属性的对象，而不是一个。
下面是向 Swagger Petstore API 发出的创建宠物的 REST API cURL 请求。
SOAP 剖析
SOAP XML 消息包含以下几个"块"：
- Envelope（信封）： 必需的部分，用于标识该 XML 消息为 SOAP 消息（与其他XML消息不同）。其namespace属性指向SOAP的最新版本。
- Header（请求头）： 可选的部分，用于存储授权属性，如 API 密钥等。
- Body（主体）： 必需的部分，用于指定在提交请求后期望从 API 接收哪些信息返回。此部分包括函数名（过程）和你希望传递的参数，这些将影响结果。在响应中，Body 部分包含 API 的响应以及所请求的信息。
- Fault（错误）： 可选的部分。如果 SOAP API 无法处理请求，它将发送在此处定义的错误消息。请求失败的原因有很多，例如，消息结构可能不符合 XML 模式定义。
为了理解 SOAP 的结构，让我们比较一下 REST 消息和 SOAP 消息。下面是向 Swagger Petstore API 发出的 REST API cURL 请求，该请求根据 petId 检索宠物。 petId 1 是一个路径参数，放在请求的资源 URL 末尾。
下面是相同请求的 SOAP 结构，以展示它们的差异：
以下是它们的不同点：
- 信息格式：
- REST - cURL 是用于构建 HTTP 请求的工具，但你也可以使用多种编程语言来发送 REST 请求。这些请求的消息负载（即消息正文）通常采用 JSON 格式。
- SOAP - 信息格式为 XML。XML 结构由 XML 架构执行。
- 请求方法（CRUD 操作）：
- REST - 在请求中提供 GET 方法，告诉应用程序接口检索某些内容。
- SOAP - 请求中不提供方法。请求会被发送到一个处理检索的过程（GetPet 函数）。
- 参数：
- REST - 宠物 ID 作为路径参数传递给端点 URL。
- SOAP - 使用 GetPet 选项在 Body 块中传递宠物 ID。
何时使用 REST 与 SOAP
REST 适用于公开 Web 服务
REST 因其使用 JSON 作为消息格式而非常适合公开 Web 服务和开放 API。JSON 的轻便、小巧以及与浏览器的高度兼容性，都使其相较于 SOAP 的 XML 格式更具优势。此外，SOAP 的 XML 消息较为冗长，而 JSON 则更加简洁。
在处理 SOAP XML 消息时，由于其组成的复杂性，通常需要在编程语言中集成 SOAP 库进行 API 调用，这相对增加了抽象层和处理开销。与此相反，REST 倡导的前后端分离的原则不依赖于客户端库，从而保持了网络服务的可迁移性、可扩展性和独立发展性。
在资源受限的网络服务环境中，REST 的优势还在于客户端可以有效地缓存 HTTP 响应。这是通过 REST 使用 URL 分离端点并利用 HTTP 请求头执行 CRUD 操作实现的，而 SOAP 则因其 POST 请求方式而难以实现缓存。
企业级应用更倾向SOAP
尽管 REST 在公开网络服务中表现出色，但 SOAP 在安全关键型应用中更具优势，这得益于其内置的消息级 WS 安全性。这种附加的安全性，使得 SOAP 更适合用于企业级软件，如客户关系管理、身份认证、银行应用、金融和电信服务，以及与传统系统的集成。
此外，SOAP 还内置了 ACID 合规性，这一点对于敏感的金融服务尤其具有吸引力。因此，在企业级应用中，SOAP 往往因其强大的安全性和事务处理能力而备受青睐。
除了 SOAP 和 REST 之外的其他选择
除了 SOAP 和 REST，还有其他一些常见的选择，如 GRPC 和 GraphQL。
gRPC 这个标准非常适合需要在带宽受限的情况下进行轻量级消息传递的微服务架构。你可以使用 gRPC 将智能手机等物联网设备与后端服务连接起来。
GraphQL 是一种越来越受欢迎的数据库查询语言。从 GraphQL API 请求数据比使用 REST 更高效。使用 REST 时，有单独的资源 URL（有时多达数百个）来暴露 API 的功能。如果你需要从两个资源中收集信息，你必须向每个资源 URL 发出请求。而使用 GraphQL，所有 API 数据都可以通过一次查询请求获取。客户端使用过滤器缩小查询范围，从而从一个 API 中检索数据。
总结
REST 和 SOAP 都是为客户端访问和与 Web 服务交互以及其暴露的功能提供标准的规范。然而，REST 是一种 API 架构风格，而 SOAP 是客户端与 Web 服务器之间的数据传输协议。因此，将两者进行比较并不完全对等。
REST 的出现是为了改善 SOAP 的局限。REST 的优势使其非常适合资源受限的公开 Web 服务。REST 的数据格式 JSON 与浏览器高度兼容，并且比 SOAP 的 XML 有效载荷所需的带宽更少。REST 还强制要求前后端的分离。这一约束对于网络服务的高效运行至关重要。虽然 REST 在某些方面已经取代了 SOAP 在公共网络服务中的地位，但 SOAP 在安全敏感的场景中，如企业级应用和金融服务中，仍然有着很高的采用率。
更多 API 管理及 API 全生命周期相关内容可以在我的 Notion 查看，我将会持续更新：API 全生命周期管理资料