拉卡拉开放平台
接口不可能一成不变。问题不在于要不要变,而在于怎么变才能让已经跑着的系统不受影响。
一句话概括:老代码不改也能继续正常工作。这是接口演进应当守住的基本底线。
| 变更类型 | 是否兼容 | 说明 |
|---|---|---|
| 新增可选字段 | 兼容 | 老调用不传也能用 |
| 新增能力 | 兼容 | 不影响既有能力 |
| 修改字段含义 | 不兼容 | 老调用会理解错 |
| 删除字段 | 不兼容 | 依赖它的调用会失败 |
| 收紧限制 | 可能不兼容 | 原本合法的调用被拒 |
需要调整语义时,更稳妥的做法是新增一个字段,而不是改变原有字段的含义。
修改字段含义是最危险的变更——调用方不会报错,只会得出错误结论。
三个阶段的时间长度应当与影响面匹配:影响面越大,周期越长。
第二点尤其重要:解析时保持宽容,能让绝大多数新增字段的变更对你完全无感。
接口标识里带版本号,是最常见的兼容手段。它的好处是新旧可以长期并存,调用方按自己的节奏迁移。
| 做法 | 适用 | 代价 |
|---|---|---|
| 地址中带版本 | 变更幅度较大时 | 需维护多套实现 |
| 参数中带版本 | 变更较小时 | 分支逻辑变多 |
| 不版本化,靠兼容演进 | 变更极小时 | 长期易积累隐性差异 |
第二点最关键:老调用不应因为新版本上线而报错,这是向后兼容的最低要求。
每一次接口变更都应留下记录,说明改了什么、为什么改、影响哪些调用方、什么时候生效。这份记录是调用方判断是否需要行动的唯一依据。
没有变更记录的升级,对调用方来说等同于随机故障。
从公告到停用,周期应当足够长。过短的迁移期会让调用方被迫冒险切换,反而增加故障概率。给足时间,比提前完成更有价值。
第一条是基础:调用点集中,升级时改动就小;调用点分散,每升级一次都是一次全身手术。
接口演进不可避免,因演进造成中断却可以避免。守住向后兼容这条底线,新旧双方都能按自己的节奏前进。
对调用方而言,最好的升级是没有感知的升级。这个目标需要接口提供方与使用方共同努力,而宽容解析是后者最容易做到的一步。
接口会一直演进,这是常态。能从容应对演进的系统,靠的不是运气,而是当初在解析与封装上多做的那一点点克制与耐心。
上一篇:日志应该记录什么:可排查性设计
24小时免费咨询
请输入您的联系电话,座机请加区号
