如何优雅的管理不同版本的API接口
如何优雅的管理不同版本的API接口
·
API版本管理方式多种多样
| 序号 | 版本管理方式 | 简要说明 |
|---|---|---|
| 1 | 域名区分管理 | 不同版本使用不同域名，v1.api.amap.com，v2.api.amap.com |
| 2 | 请求URL path区分管理 | 同一域名，api.amap.com/v1/，api.amap.com/v2/ |
| 3 | 请求参数区分管理 | 同一域名，请求参数中带version=v1/v2/v3等，然后识别具体版本执行对应方法 |
各方式的优缺点
| 序号 | 版本管理方式 | 优点 | 缺点 |
|---|---|---|---|
| 1 | 域名区分管理 | 1、采用多应用部署，不同版本接口完全隔离；2、部署在一个应用上，通过域名识别进行分发 | 1、函数不能复用；2、函数能复用 |
| 2 | 请求URL path区分管理 | 可以创建不同的controllers，功能水平扩展，不影响老版本 | |
| 3 | 请求参数区分管理 | 功能水平扩展，不影响老版本 |
版本管理的一点思考
API日常接口变更不可避免，但若变更太频繁，就要思考最初的需求是不是有问题，变更API版本的目的是什么，每个版本使用用户都不同等等方面的问题；
如果不同版本的API仅是功能更强大了，比如原来不支持附件上传，新版本支持附件上传，这种场景的API版本变更就没意义，更合理的是单独发布一个附件上传的接口，降低功能间的耦合。
在开发接口时始终要记住一点：尽量将功能的颗粒度降到最低（需求分析、模块设计阶段），不要做多功能融合的接口。
参考
权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)