什么，api竟然有版本

前言

---

第一次接触接口版本的时候，应该是dubbo，就是它在配置服务端和客户端的时候需要写上对应的版本号，这也是我觉得dubbo麻烦的地方，很多公司也因此改为feign这样更加便捷的rpc。（虽然说dubbo有很高的性能，基于netty实现通讯，但是开发便捷在大部分时间还是比性能强，即使在我上家几万qps的情况下，虽然技术负责人有说过考虑换dubbo，最终还是在用feign，嘿嘿）

在第二次接触到api版本说法，是在我做全链路灰度项目的时候，当时有个老哥在讨论这个方案的用途的时候，他说应该去兼容不同api版本，其实那玩意是为了代替现有蓝绿灰度的。

到这里，我就有点奇怪了，api版本？

为啥我平时的接口都是只有一个？

对吧，在众多项目里头，基本上都是只有一个版本，而且是最新的版本，但是它也要兼容之前版本内容，当有内容冲突的时候，需要一起更新迭代。

api版本

---

从上面三种api版本，我们可以找到现在的api模式上版本兼容，也就是现在的版本会兼容之前版本的内容，不会说忽然出现断层，就是我上期我们俩聊得好好的东西，下一期干掉了，接口直接异常。

第一种是外部多个版本对应我们一个版本，第二种是多个版本互相对应，第三种是采用兼容的版本控制。

• The Costs of Versioning an API

日常业务其实采用第三种兼容性版本已经足够解决，但是有时会出现现有的需求已经跟之前有所差异导致接口不再适用，这时一般会新起另一个接口来处理新的逻辑。

业界api做法

---

之前接过百度开放平台api，一开始会有一个url，过了一段时间发现出了个新的接口叫/v1/xx，就是在原有的基础上加多了个版本号，这就是另起一个接口的做法。好处当然是简单快捷，如果是采用ddd的设计，其实外层都是adapter，内层逻辑做了层层隔离，就不会说随着业务发展一直在变动，提高整体的稳定性。

前几天看了vivo的api设计文章，里面提到了在参数里头添加version做法，我觉得这个也是很好的idea，就是接口原本就支持版本扩展，只不过在代码层面做的一层分隔。优点是做到了可扩展性，可迁移，大部分api接口都可以通过加上version的属性来提高版本兼容，缺点是需要代码上去隔离，会增加复杂性。

「本人的看法」

在业务前期或者发展阶段，可以采用第一种兼容版本做法，当无法满足需求的时候另开一个接口，因为这种情况是比较少的。我们做的业务一般是面向内部服务，比如说内部用户，内部应用，调用者跟提供者都是我们，这时升级版本的时候，呼一声一起上线就完事了。

但是对于有外部的开发者，这就不好升级了，比如说一个接口对了几百家，忽然说改就改，难度非常大的，推进也会很难，比如说开放平台接口，所以这时用第一个方法可以解决大部分场景。

第二种在参数加上version属性的，适合那种有很多版本的情况，比如说app，用户可能用2000年，可能有些用的最新的，像小米的死忠粉，一直拿着古老的小米6是吧，就是不肯换手机是吧，好家伙～ 那这时意味着接口会有很多版本，如果你每次都新增一个接口，完犊子了，接口文档密密麻麻～

当然有些内部员工用的app，如果版本不兼容我们会强制更新到最新版本，这就是硬气的地方，如果是客户还得考虑下用户体验，嘿嘿～

实践

---

之前我在搞开放平台的时候，是有个对外鉴权的算法的，但是当时设计不太好，然后对接的商家也有20来家了，
后来这个签名算法我改了一版，做到真正比较成熟的签名，这时问题就来了如果去升级这个api呢？

我的想法💡：两个系统来自，之前有想过通过灰度的手段来慢慢切过来，一部分用户用新的，一部分用旧的，其实想想不太靠谱，你升级完了，别人还在用旧的，你说逻辑上让不让它用旧的。

所以百度开放平台设计是合理的，就是新开一个接口，让对方去重新接入，当大家都升级完的时候，我们也可以看流量是否还有从旧版本溜进来，没有的话就把它下线掉。

这里又要贴下之前阿里文娱开放平台设计，我们可以看到这是一个完善的api管理，就是不会随意将接口暴露到外面去访问，是可控的。