API 需要随着时间的推移不断演变，包括添加新功能、修复错误和进行改动。如何在不中断客户端应用程序的情况下引入和跟踪这些更改？答案就是 API 版本控制。通过对 API 进行版本控制，可以在不断改进的同时，确保构建一个强大且可扩展的产品。
什么是 API 版本控制？
对 API 进行版本控制是一种跟踪更改和管理各种迭代的过程。本质上，版本控制允许创建多个共存且独立运行的 API 版本。这种方式使得在添加新功能、进行更新和删除旧功能时，可以将对用户服务的中断降至最低。
为什么 API 版本控制很重要？
正确的版本控制是保持项目灵活性并确保兼容现有工具和新工具的关键步骤。如果没有适当的版本控制，对 API 的修改可能会导致意外错误，进而导致客户端中断。随着时间的推移，可能需要对 API 进行更改，因此从一开始就实施正确的 API 版本控制是明智的选择。
一个有效的 API 版本控制策略不仅有助于提升项目的灵活性，还能增加与更多工具的兼容性，并维护向后兼容性。在项目过程中，这种策略还可以降低引入新功能的成本，并清晰地向用户传达更改内容。每个 API 版本号都有自己的发行说明、迁移指南和更新文档，这种做法促进了与用户的信任关系。
何时应对 API 进行版本控制？
对 API 进行重大更改时，采用 API 版本控制策略是明智的选择。不同版本的推出使用户能够按自己的节奏逐步采用新功能。版本控制还支持进行安全更新，而无需强制 API 用户进行需要停机的升级。
当 API 支持多个客户端平台时，版本控制允许用户继续使用其平台的 SDK，而无需担心其他平台的更新。
什么时候不应该对 API 进行版本控制？
然而，版本控制并不是适用于所有情况的最佳解决方案。对于次要更新或 bug 修复，制定完整的版本控制策略可能会引入更多混乱而非好处。此外，在只有一个或两个用户的情况下，例如仅在内部使用的 API，同时更新 server 和 client 可能更为实际。类似地，当引入非中断性或临时更改，或在分支上进行不会影响客户端的修改时，版本控制的必要性也较低。
如何进行 API 版本控制
如果 API 版本控制适合需求，了解如何调整版本控制以满足具体要求是关键。首先需要考虑的是选择合适的版本标记方法，主要有以下几种选项：
- 语义版本控制（SemVer）：采用格式 MAJOR.MINOR.PATCH。有关语义版本控制的详细信息，请访问 semver.org。此方法有助于跟踪向后兼容的更改、功能添加和 bug 修复。每次出现重大变更时，主要版本号会递增；向后兼容的功能添加和 bug 修复则通过次要版本号进行标记。
- 基于日期的版本控制：将每个 API 版本号与其发布日期关联。这种方法在某些情况下可能很有用，因为发布时间顺序比语义清晰度更相关。
- 基于终端节点的版本控制：在版本范围仅影响某些具有独立资源的终端节点时，这种方法可能会有所帮助。
没有“最佳”方法，选择哪种系统取决于哪些信息最能帮助跟踪 API 的更改。分析需求和期望结果将有助于决定最适合的版本控制策略。
API 版本控制的类型
接下来，需要确定用户如何指定他们想要使用的 API 版本。以下是一些选项：
| 版本控制类型 | 基本 | 例子 | 优点 | 缺点 |
|---|---|---|---|---|
| URI 版本控制 | 版本号将合并到 URL 路径中。 | http://www.example.com/api/1/products | 易于理解和实施。明确分离的 API 版本。 | 可能会变得杂乱无章。REST 架构不推荐。 |
| 查询参数 | 版本号将作为查询参数附加到 API 终端节点中。 | http://www.example.com/api/products?version=1 | API 版本明确分离。易于实施。 | 对于 API 使用者来说不太直观。可能会导致 URL 长而混乱。 |
| 基于标头 | 版本号是一个特定且唯一的标头字段。 | curl -H “接受版本： 1.0” | 遵循 REST 原则。使 URI 专注于资源。 | 不那么直观。需要更多的工作来检查 API 请求。 |
| 内容协商 | 版本基于表述状态或媒体类型。 | curl -H “接受： application/vnd.xm.device+json;version=1” | 占用 URI 空间更小。无需 URI 路由规则。版本表示在资源层面，而不是整个 API。 | 通过浏览器进行测试和探索时，不太容易访问。 |
这些技术各有不同的目标和优势，因此应根据特定项目的要求来确定最适合的技术。
如何构建 API 版本控制策略
规划出最适合约束和目标的方法和技术后，可以根据 API 版本控制最佳实践制定策略。首先，需要评估工程范围并定义版本控制策略。REST（表述性状态传输）是一种流行的 API 架构，用于构建 Web 服务，通过标准 HTTP 方法访问资源。将版本控制与 REST API 结合使用，可以在不破坏 API 使用者现有内容的情况下，向 API 添加新功能、修复错误和删除旧功能。构建 REST API 时，需牢记以下版本控制原则：
清楚地传达更改
使用 REST API 的关键在于避免客户端和服务器之间对资源位置的混淆。若未清晰沟通服务器上的变化，可能会导致问题。考虑发布说明、迁移指南和更新的 API 文档，以确保所有人都了解最新情况。也许值得考虑较长的时间表，为用户提供足够的时间来准备和实施更新。
使用语义版本控制
语义版本控制最符合 REST 原则，因为 REST API 是无状态的，终端节点不受外部约束的影响，理论上彼此独立运行。设置 SemVer 可以将端点与任何类似于 state 的内容隔离开来。
尽可能保持向后兼容性
REST API 应保持统一和一致，理想情况下不应有突破性变化。虽然长期保持向后兼容很难，但仍应尽力做到。例如，新参数应具有默认值，新功能应通过新终端节点和新版本引入。避免从 API 响应中删除现有字段，尤其是在拥有良好的弃用策略时。
逐步弃用旧版本
有效的弃用策略应包括明确的时间表。在弃用期间支持旧版本，并在 API 文档中清晰记录弃用端点。同时，明确告知用户弃用的原因、新版本的好处、可能遇到的问题及解决方法。充分的过渡期支持有助于减少中断，促进开发人员和 API 使用者之间的信任。
API 版本控制最佳实践
API 版本控制策略的许多方面取决于应用程序的特定需求，但有一些一般准则可以作为 API 版本控制的最佳实践。
确定文档的优先级
全面的文档应准确反映整个 API 的当前状态，并根据最新的 API 版本进行更新。确保每个新版本都有明确的更改说明，以避免用户困惑。用户转向新版本的阻力可能出乎意料地小，因此清晰的文档非常重要。
与客户保持畅通
良好的沟通至关重要。了解用户需求及新版本如何影响其工作流程至关重要。应提前建立沟通渠道，通知用户即将到来的更改和新版本。这些渠道还可以用于收集用户反馈，以了解其需求和期望，进而帮助构建 API 的未来路线图。
规划安全性和可扩展性
虽然大多数 API 版本控制集中于功能方面，但安全性和可扩展性同样重要。新版本的推出应能够抵御安全威胁，而旧版本可能仍存在已修复的漏洞。此外，随着使用量和数据量的增加，API 需要应对更大的负载。从一开始就纳入自动化安全检查、漏洞评估和可扩展实践。将安全更新和补丁版本作为每个版本的优先级，确保每个主要或次要补丁都得到支持。这包括已被替换的补丁。沟通至关重要，因为可能有法律义务通知 API 用户数据安全在每次更新中的保护情况。
彻底测试
在 API 发布给用户之前，应捕获尽可能多的问题。对每个新版本进行单元测试、集成测试和回归测试，避免在升级某部分时意外破坏其他功能。每个阶段进行全面测试有助于确保向用户提供可靠的产品。自动化工具可以大大简化测试流程。
如何测试 API 版本
首先，需要对新的 API 版本进行全面测试，以确保其满足所有功能规范。可以通过以下几种方法进行测试：
单元测试
单元测试涉及测试单个代码单元。例如，验证每个终端节点是否按预期工作。考虑一个只接受一个字母的终端节点，如果该字母在 ASCII 值的某个范围内，它会将字母移动指定的位数。以下是一个函数示例：
const shiftLetter = (letter, key, rangeStart, rangeEnd) => { const rangeLength = rangeEnd - rangeStart; const code = letter.charCodeAt(0); if (rangeStart <= code && code < rangeEnd) { let n = code - rangeStart + key; if (n < 0) n = rangeLength - Math.abs(n) % rangeLength; return String.fromCharCode((n % rangeLength) + rangeStart); } else return letter; };
示例测试函数如下：
const testShiftLetter = () => { if (shiftLetter("L", 3, 65, 91) != "O") throw "Assertion error"; // 测试基本情况 if (shiftLetter("s", 14, 65, 122) != "g") throw "Assertion error"; // 测试环绕和自定义范围 };
这些测试应自动化运行，以确保 API 的每个部分仍按预期工作，工具如 GitStream 可以帮助实现这一点。
集成测试
集成测试涉及测试多个代码单元如何协同工作以产生正确的结果。以下是一个更复杂的测试示例：
const testCaesar = () => { if (caesar("HELLO", 1) != "IFMMP") throw "Assertion error"; // 测试基本情况 if (caesar(caesar("DECRYPTED TEXT", 19), -19) != "DECRYPTED TEXT") throw "Assertion error"; // 测试负键解密 };
集成测试关注于多个单元的互动以及最终结果的正确性。
系统测试
系统测试涉及测试通过 API 构建的整个应用程序，检查所有部分如何协同工作。这种测试较难实现，但如果为每个新版本提供了良好的文档和迁移指南，可以使用 API 构建的演示进行测试。
结论
在项目开始时考虑这些因素可能会令人畏惧，但前期投入的时间和精力将为整个项目生命周期带来回报。构建 API 版本控制策略时的努力绝对是值得的。周到的规划和最佳实践的实施将打造一个强大、可扩展的 API，并确保其长期稳定性和适应性。需要注意的是，软件开发是一个不断进步的领域，因此开发人员需跟上最佳实践和新方法的改进，以实现版本间的平稳过渡，提升最终用户体验，并帮助建立与客户的长期满意关系。
