永不过期的 API 密钥带来的问题
一个多年前签发、从未轮换、至今仍然有效的密钥并不是一种便利。它是一个多年来没有人真正检查过的隐患。
为什么 API 版本管理应该乏味而稳定
服务商宣布一个重大的新 API 版本，通常就是在向每一位已有集成的客户宣布一个他们并未要求的项目。即使是沟通得很好的破坏性变更，也意味着有人必须安排时间阅读迁移指南、更新请求或响应处理、进行测试并部署，而时间表由服务商的路线图决定，而不是由该客户自身产品中发生的任何事情决定。
我们认为 API 的稳定性本身就值得作为一个设计目标来对待，而不是缺乏进展的表现。一个响应结构一旦发布，就应该始终保持开发者最初基于它构建时的含义。新字段可以作为可选的附加内容加入，就像海拔、IP 威胁和网络详情是叠加在标准响应之上的可选附加项，而不是对其强行重构。不应该悄悄发生的是：现有字段的含义改变、某个状态码被挪作他用，或者在同一版本号下重构结构。
破坏性变更在这个行业如此频繁的部分原因在于，它们对服务商来说代价低廉，对客户来说却代价高昂，而双方很少直接就这种不平衡进行协商。推出一个更简洁的内部模型，对服务商自己的团队来说是一次正当的工程胜利。但一旦它迫使每一个下游集成随之改变，而且时间表由服务商而非客户掌控，它就变成了一种负担。
这并不意味着 API 永远不应改变。它意味着变更应尽可能以增量方式进行，而在确实无法避免破坏性变更时，这种情况应当足够罕见，让客户可以相信，他们所依据构建的结构在数月甚至数年后仍然可用，而不是需要时刻关注变更日志来防范的东西。稳定不等于停滞。它是一种承诺：今天的集成工作不会附带一个没人告诉过您的过期日期。
除了客户的好感之外，我们坚持这一立场还有一个出于自身利益的理由。我们运行的每一个兼容主机，都依赖于长期忠实地匹配另一家服务商的结构，而这只有在结构一经匹配便值得作为稳定目标来依赖时才行得通。一家把自己的 API 接口视为可随时丢弃、只要方便就重新设计的公司，它的兼容性保证也算不上真正的保证。稳定必须是一种处处适用的习惯，否则它在任何地方都不算真正适用。
在这里，平淡并不是批评。一个 API 版本在多年之后仍然与您最初集成时完全一样地运行，这并不证明什么都没有改进。它证明的是，改进是以不需要您察觉的方式发生的，而这正是良好版本管理规范的全部意义所在。