在写 App 的 API 的时候,新老接口版本怎么处理优雅?

[xiaotianhu]

比如一个接口 A 在老的 0.9 版本中 返回{"aaa":"bbb"}

但是在 1.0 新版需要返回{"aaa":{"ccc":"bbb", "bbb":"bbb"}}

这样互相不兼容,就需要不断的判断版本号,或者放弃老版本 兼容成本太高 非常蛋疼 代码乱七八糟的 有什么优雅的解决方案?

[qqmishi]

维护两个版本，请求的时候带上版本号
比如 leancloud 的 REST API 在域名后衔接版本号，代表使用的 api 版本

[FanError]

同楼上
api.xxxx.com/v1/yyyy
api.xxxx.com/v2/zzzz

[xiaotianhu]

@qqmishi 这样在 git 或者线上不就是有两套代码了 这样增加了运维的成本啊

而且可能有 v3 v4 呢

[qqmishi]

@xiaotianhu 如果贵司的 api 是公开的，供第三方开发者使用的话，请一定记着维持兼容性，不然每次升级都大改的话，开发者只会怀疑你们一开始就没设计好，然后就没人用了。这种情况给开发者一个缓冲阶段，让他们在期限前升级到新版本，然后就可以放弃旧版本了。

如果仅供自己使用的话，要求用户强制升级，旧版本直接扔掉就行了。

[dphdjy]

从设计原则，版本写在 header 里面
从方便新手，写在 URL 里面

[JiShuTui]

新版 APP 上线之后，用户并不会立刻全部都下载新版本 APP ，所以你需要同时维护两个版本 API ，两套代码。
然后你就需要一直关注后台数据，查看用户的 API 版本分布，当某个版本的请求数接近于零时，就可以不再维护这套代码了，你可以删掉，但是建议保留着。

[msg7086]

@xiaotianhu API 不兼容的话本来就会有两套代码，增加啥成本？

[kkzxak47]

直接写新的，不修改。后期老接口看情况逐步淘汰

[xiaotianhu]

@qqmishi 是自己的

不过频率太频繁了
经常两周不到,就要考虑兼容上一个版本的某些功能这样了....

[xiaotianhu]

@msg7086
运维的各种监控 /发布系统 /分布式等等都是针对 一套代码 来实现的
没有考虑 多套 的问题.所以会增加 运维开发 的成本.

[skydiver]

@xiaotianhu 一套代码可以提供两个 api

[qqmishi]

@xiaotianhu 怎么会这么频繁，贵司的 api 是不是有设计不当的地方？

要真是这种更新频率而且前后不兼容的话，建议还是让运维着手开发适配多套 api 的系统吧，客户端的升级必然是需要一段时间的，新旧 api 需要共存。

判断可以像 @dphdjy 所说，放在 URL 或者 Header 里，更新版本号只需要更新改变的 api ，不变的可以继续用原有的。（其实完全可以用客户端版本号在服务器端判断应该用哪版 api 的）

[msg7086]

@xiaotianhu 系统还是一个呀，只是 API 接口实现不同了，又不是单独开个新项目。

[rainybowe]

一般两种方式，写在 url ，写在 header 中。写在 url 中的方式不灵活而且不太 restful ，可以在 request header: accept 中加入版本号， https://www.troyhunt.com/your-api-versioning-is-wrong-which-is/这里的设计方式可以参考一下。我自己的 django 项目中则是通过一个 decorator 优雅路由。