SaaS 时代，如何确保 API 版本控制的一致性？

摘要

要点：随着 SaaS API 的广泛使用，处理重大更新和变更的方法出现了不一致性。API 发布者在追求向后兼容性时，往往忽略了性能、依赖性和 wireformat 兼容性等问题。这可能会削弱客户对版本控制的信任，迫使发布者支持旧版本并加剧了版本控制问题。

引言

语义版本控制（SemVer）通用标准面临的挑战是如何处理向后不兼容的重大变更。SaaS API 的普及和现代软件构建系统的复杂性要求软件发行商和使用者对版本控制有一致的理解。

本文内容

本文探讨了 SemVer 中向后兼容性和重大变更的概念，用实际示例说明了 API 的不同兼容性类型，包括 API 兼容性、ABI 兼容性、伙伴 API 兼容性、性能兼容性、Wireformat 兼容性、系统级兼容性、可降级性、数据收集兼容性和依赖兼容性。

API 兼容性

向后兼容性通常关注 API 签名的直接变更，如参数和返回类型的修改，这可能需要开发者调整他们的集成代码。

ABI 兼容性

在 Java 中，即使保持了 API 兼容性，ABI 兼容性可能因方法签名的变更而丧失，导致需要重新编译以使用新版本。

伙伴 API 兼容性

SaaS 平台强调产品的互操作性，但伙伴 API 之间的不兼容变更可能迫使客户同时升级多个依赖项。

性能兼容性

实现相关的变更通常不视为破坏性变更，但任何明显增加调用延迟的变更都可能影响客户体验和留存。

Wireformat 兼容性

选择合适的序列化工具对 API 的模式演化和数据传输至关重要，不当的变更可能导致需要更新所有客户端应用程序。

系统级兼容性

在多样化的环境中，如移动操作系统，SDK 更新可能导致与系统级 API 的破坏性变更。

可降级性

如果新版本的 API 用户无法回退到旧版本，这可能被视为破坏性变更。

数据收集 / 存储 / 保留兼容性

新版 API 改变数据收集、存储或处理方式应被视为重大变更，因其潜在的法律影响和对软件分发的影响。

依赖兼容性

SDK 的依赖项变更可能引入破坏性变更，应只依赖稳定的库以减少这种变更。

隐式合约兼容性

虽然 API 表示具体合约，但客户从他们的角度解释合约，打破隐式合约可能导致破坏性变更。

总结

SaaS API 必须细致地了解版本控制和重大变更的影响，平衡向后兼容性、可升级性以及现代化和迭代之间的关系。通过深入理解兼容性和重大变更，API 发布者可以做出明智决策，改进产品并培养用户信任和忠诚度。

作者介绍：Ashwin Raghav Mohan Ganesh 是 Google IDX 项目的工程主管，有20年的软件开发和团队领导经验。