API演进的三种策略

分布式系统里改 API 不能想改就改，因为总有别的服务依赖着这份契约，三种应对思路：优先做向后兼容的改动（比如只加可选字段），完全不影响现有调用方；万不得已要做破坏性变更时上版本号（endpoint 里带 /v2 或者放进 HTTP 头），让新旧版本并存一段时间，但调用方迟早还是要迁移，需要协调；第三种思路更激进，靠 REST 的超媒体特性（HATEOAS）让响应里自带”下一步能去哪里、能做什么操作”的链接，调用方跟着链接走而不是硬编码路径，这样服务端调整路径结构时调用方基本不用跟着改，这是 Richardson 成熟度模型定义的 REST 最高等级。发散：前两种策略是在”改动方”和”调用方”之间显式协调，第三种是把这种协调完全从人力沟通转移到了协议设计里——但代价是双方都要接受一套更复杂的、真正遵循超媒体理念的 API 设计范式，实践中采用率并不高。