后端接口如何做版本控制？

[rockyliang]

假设有下面一个场景： 1.0 版本客户端的用户注册功能，手机号是可选填的，即使用户不输入手机号也能注册，对应的后端接口 URL 是 v1/reg

但到了 1.1 版本，手机号改为了必填，这时候有两种做法：

1 ）做一个新的 v2/reg 后端接口给客户端使用，缺点是，需要同时维护 v1 、v2 两个版本的接口，而且会造成两个接口的代码大量冗余，除了“手机号是否必填”不一样以外，其它功能的代码都一样

2 ）让客户端把版本号传过来，后端接口根据客户端版本号来判断手机号是否必填，缺点是，接口里会充斥着很多对客户端版本号进行判断的代码，例如：

if (appVersion == "1.0") {
    // do something
} else if (appVersion == "1.1") {
    // do something
} else {
    // do something
}

上面哪种做法更好呢？或者各位大神有没有更好的版本控制方案？

[deplives]

用路由去控制，domain/v1/xxxx domain/v2/xxxx 不要在业务代码里判断版本，这样后期维护成本太高了

[Huiao]

1.0 版本的代码和 1.1 版本的代码并存。网关通过 v1/v2 去转发

[wellsc]

header 加版本号

[Huiao]

1.0 和 1.1 的服务并存

[Leigg]

同 1 楼，不要在代码里面写 if elseif，会成为噩梦的开始，

[kaneg]

URL 加版本 /v1/abc, /v2/abc 。既要支持多版本，又要代码完全不重复是不可能同时满足的，鱼与熊掌不可兼得。只能尽量通过抽取公共代码的方式来消除重复代码。毕竟对外的 API 就是这种特性，一旦暴露即等同于固化。除非根本就不管兼容性的问题。

[ch2]

通常的做法是 1

[initd]

GraphQL

[raaaaaar]

我看见比较多的是 1，代码抽象出来更好，加分支的话。。

[encro]

首先排除一个最简单做法：新增一个 reg2 方法。

[janus77]

你这样无论如何都要有 2 套逻辑共存。注意我说的是逻辑，无论是客户端还是后端，所以你维护两块代码是不可避免的事

[fewok]

有没有想过，这种不好做监控

[9yu]

K8s 生态里面都是 /v1alpha/, /v1beta/ 这样的，短期可以同时保留

[chinvo]

正确做法是分开做 controller, 版本放到 url 或者 header 里

[Maboroshii]

新增一个 v2，然后 v1 除了修 bug 不维护了啊，后面的客户端更新就只能用 v2

[rockyliang]

@kaneg 比较赞同你的看法，我目前能想到的也是只能通过抽取公共部分来消除不同版本接口之间的重复代码，感谢你的回答~

[rockyliang]

@Maboroshii 新增一个 v2 的话，v2 和 v1 两个接口的代码就会大量重复，不过这种倒是可以通过抽取相同部分的代码来消除。v1 和 v2 两个接口只写差异部分的代码，相同部分的则通过调用共用函数 /方法来执行。感谢你的回答:)

[wd]

和客户端对接的时候一定要注意客户端那边肯定是新旧版本同时共存的，他们一般没有办法控制用户那边的更新情况。所以你这个答案很明显，必须是共存。除非说不支持旧版了。

[polyang]

这种明显是用第一种方案。
在代码里判断版本号会成为你噩梦的开始

[rockyliang]

@wd 其实问题里我提到的两个方法都是可以做到共存的，差别就在于：第一种需要新增一个接口；第二种不需要新增，但需要在同一个接口里判断客户端版本，然后执行不同的逻辑。