最近有个接口系统升级，应业务的需求，他们要改动接口参数，增加几个字段，但是要求用到这个接口的其它系统都改造，以适配升级。这其实是有些问题的，尤其从架构层面，接口层的改造影响了关联系统。
其实对接口系统来说，他需要做的就是能够"向后兼容（Backward Compatibility）"，或者叫"向下兼容"。
向后兼容指的是：接口（或系统）的新版本，能够继续支持旧版本的客户端，旧应用无需做任何修改就能正常工作。
改动接口参数，但不让关联应用进行改造，意味着改动不能破坏旧调用方式，这正是向后兼容的核心要求。原则上，这应该是对接口系统的最基本要求，不能因为自己的变更影响关联系统。
改动接口参数，这个行为本身有多种做法，只有兼容性的修改才能实现不让旧应用改造，
✅ 兼容：新增可选参数（带默认值）、增加新接口但保留旧接口、放宽参数约束（如将必填改为可选）。
❌ 不兼容：删除原有参数、修改参数类型、将可选改为必填、改变参数语义等。
如果改动属于前者就可以称为向后兼容的接口变更，如果属于后者，则旧应用必然出错，就不能说不让改造了。
因此，尤其针对向外提供接口服务的公共系统来讲，一旦要改造，"向后兼容"，这是必须考虑的，否则就会牵一发动全身，对关联系统不够友好，可能对相关系统的稳定运行产生一定影响。
再进一步理解，既然有"向后兼容"，有没有"向前兼容"？
答案是存在"向前兼容"，它的方向和"向后兼容"正好相反。"向前兼容"可以理解成站在旧版本的角度，旧版本能接受新版本产生的东西，例如，
消息协议：旧版解析器遇到新增的字段，忽略不认识的字段（如 Protobuf、JSON的"忽略未知属性"）。
数据库：旧版表结构增加新列后，旧版插入语句仍然有效（新列有默认值或允许NULL）。
文件格式：新版Word保存的.docx，旧版Word能打开并显示可读内容（忽略不支持的新特性）。
HTTP API：服务端给响应增加新字段，旧客户端不读该字段仍能正常工作。
"向后兼容"和"向前兼容"比对，
概括讲，"向后兼容"和"向前兼容"是互补的两个方向，都是衡量系统演化能力的重要指标。
实践操作中，向后兼容比较常见的，因为设计时只需保证新代码不破坏旧调用。向前兼容更难，因为旧版本无法预知未来的变化，通常需要约定"可扩展的格式"。
如果您认为这篇文章有些帮助，还请不吝点下文章末尾的"点赞"和"在看"，或者直接转发朋友圈，
微信公众号：@bisal的个人杂货铺 腾讯云开发者社区：@bisal的个人杂货铺 头条号：@bisal的个人杂货铺 CSDN：@bisal ITPub：@bisal 墨天轮：@bisal 51CTO：@bisal 小红书：@bisal 抖音：@bisal
