在常规的业务开发中假设我们的接口提供给客户端同时提供移动端应用,但是在产品迭代的过程中客户端迭代速度更快需要将部分接口结构更新原来的接口又不得不升级,但是移动端还是保持原来接口结构。遇到类似的情况我们可以考虑使用 API 版本控制
常用的API版本控制模式有以下三种:
使用这种模式意味着服务端每个 API 只提供一个版本,如果 API 升级结构调整所有调用方都需要同步更新 API 结构,任何 API 的修改可能都会影响到所有用户
该模式下同一个名称 API 可以建立多个版本,API 调用方会根据自己的需求选择使用对应的API版本。新版本和旧版本同时存在,即使用户使用是旧版版也不会受到影响
每个 API 只有一个版本,API 需要兼容以前老版本 API 的功能,所有版本用户都调用同一个版本 API,通过内部兼容的方式实现新旧版本 API 互相兼容
新功能直接在旧 API 上修改,API 修改部分同步给客户端强制客户端一起升级(热更新),在用户体验会受到一定影响
更换 API 名称,新功能使用新的 API 名称,新版本客户端调用使用新 API 名称
// old http://test.mesh.cn/api/user/login // new http://test.mesh.cn/api/user/newLogin
在 URI 上添加版本号,URI 中直接标记使用那个版本,如果URI不携带版本号默认使用最新版本
// old http://test.mesh.cn/api/user/login // new http://test.mesh.cn/api/v2/user/login
参数携带版本号,即在每个 API 请求后添加一个 version 参数表示请求是那个版本
// old http://test.mesh.cn/api/user/login // new http://test.mesh.cn/api/user/login?version=2
该模式是基于版本模式下的改进方案,将版本信息从 API 中隐藏
通过HTTP头部做版本指定
在处理 API 时,服务端根据 API 调用方在 request header 中设置的 api-version 来判断,进而执行不同的逻辑处理。
// request header info GET http://test.mesh.cn/api/user/login api-version: v1
通过客户端 token 进行判断
客户端与服务端交互时,都会携带一个附加的 releaseToken字段,服务端可以根据这个 token 去判断对应 API 版本(releaseToken 与版本映射)
基于 API 版本控制还有许多其他方案,没有一个完美的方案可以适用于任何场景,在实际处理问题时我们还是需要根据具体问题具体分析。