
版本号格式: 1.0.1
如果说第一版上线后有些 UI 和界面功能上的改动,使得老接口不可用。发布 1.1.0 版,为了 APP 能支持老接口,服务器上的项目是 copy 一份然后将 git branch checkout 为 1.1.0 。并新增一个 Apache/nginx 虚拟机来接收请求吗?
http://api.aaa.com/v2/[controller]/[action]
1 airyland 2017 年 4 月 19 日 为什么不能同个项目 v1 v2 并存。 |
2 ytmsdy 2017 年 4 月 19 日 via iPhone 通过 url 进行区分! api/v1/news/ api/v2/news/ 前台进行区分 |
3 luoyou1014 2017 年 4 月 19 日 建立 module 1.1.0 , 1.1.0 中的 controller 全部继承 1.0.0 ,这样既保证老接口的访问,又避免新接口去把老接口的功能实现一遍。 |
4 tlday 2017 年 4 月 19 日 via Android 可以用 nginx 的负载均衡模块区分 url 转发,不用开新虚拟机 /host 。 |
5 tlday 2017 年 4 月 19 日 via Android @luoyou1014 这样处理的话,未来版本多了,继承层级不会爆炸吗? |
6 luoyou1014 2017 年 4 月 19 日 @tlday 分三位版本号,最小位变动不加 module ,中间位变动根据接口的是否与老接口重合的情况来决定是够加 module ,最高位变动必加 module 。 我们公司差不多有了七层继承,开启 opcache 性能不是问题,偶尔调试有点麻烦,不过这样的好处就是新版本代码绝对不会影响老版本代码。 如果你们公司业务做的真的非常好,可以定期重构,减少继承层级。 |
7 tlday 2017 年 4 月 19 日 via Android @luoyou1014 好吧,虽然不太能认同你们的做法,但是确实是继承的新姿势 get√,我从来都是开两套…旧的打个 tag/branch ,只做 bug fix ,不再添加新功能。新的继续迭代。因为我觉得版本更新时覆盖更新是大忌。 |
8 Immortal 2017 年 4 月 19 日 app 的网络库底层可以封装点标志信息到 header 头里 然后用 nginx 反向代理到各个后端服务 这样不好的一点是偶尔改了一个接口 整个都要反代过去 除非配置里加判断 不过一般也就维护几个版本 迭代几次 强更一次 |
9 hl 2017 年 4 月 20 日 apigateway |
10 willakira 2017 年 4 月 20 日 不需要,直接在旧接口的基础上开发新的服务 你这才从 1.0.0 到 1.1.0 就不想兼容旧接口了么… 如果每次版本升级都是一个新的 repo ,一些影响多个版本的旧 bug 的修复和部署会非常非常痛苦。 |
11 yimity 2017 年 4 月 20 日 如果只是继承好处理,但是后端的 model 数据库字段等怎么处理? |
12 ltye 2017 年 4 月 20 日 也可以在 header 里增加版本号~ |
13 blacklee 2017 年 4 月 20 日 1.0.0 到 1.0.1 绝对需要 API 方面的兼容,这种兼容都做不到,构架师好辞职了。 |
14 tshwangq 2017 年 4 月 20 日 @luoyou1014 你这是真遗传,真继承啊。 不过真实需要继承场景的东西都被版本号给废了 |
15 tshwangq 2017 年 4 月 20 日 我的建议,变动不大的,没有根本冲突的。不需要维护几个 api 。 代码累积改动大,已经有不可兼容或者兼容代价太大,考虑发布不同的版本。 并且做好 api 生命周期,设定好旧版本死亡时间。 |
16 luoyou1014 2017 年 4 月 20 日 |
17 realpg PRO 三位版本号的话,接口发生变动,必然要修改第二位版本号的…… 第三位版本号是用来修正小问题的 |
18 mhycy 2017 年 4 月 20 日 一个大版本够了,前端请求没必要区分小版本更新,一个大版本之下再狗屎都要完全兼容 |
19 Observer42 2017 年 4 月 20 日 学习了。。用继承 我们是 1.0 - 1.1 不允许有不兼容,只能添加 api , 1.x - 2.0 可以不兼容,直接写新 controller 。但 1.x 的 controller 保留直到没有服务调 |