在代码层面大家是怎么管理 API 接口版本的呢？

[coosir]

当我们提供API接口的时候，版本可能是0.1, 0.2, 0.3等不断变化。
比如 GET https://www.v2ex.com/api/v0.1/members/show.json

考虑到移动端更新不及时，必须保证所有版本都能正常工作。

1. 曾经看过一个team的代码，直接在代码里面 if else 判断版本号不同版本分别处理。这在版本号很多的时候简直是个灾难。
2. 每个版本的功能代码放到一个子目录。文件会出现比较多的重复，使用一些框架比如Slim或Lumen的时候要去改写路由部分。

在代码层面，大家都是怎么做的呢？有没有比较好的实践？

[abcfyk]

为什么要暴露API的版本给客户端知道？ 客户端只需要知道如何调用这个API能取到数据，就够啦。

[zieglar]

一个 API 版本一个入口文件

[coosir]

@abcfyk 每个版本的客户端是死的，处理返回的数据的方法也是死的。要让不同版本的客户端都正常工作，不区分版本是很难做到的。

[coosir]

@zieglar 嗯，然后呢？其他代码怎么按版本处理的？

[jokester]

unit test

[luin]

Accept: application/vnd.example.v2+json.(https://tools.ietf.org/html/rfc4288#section-3.2)

[sodatea]

senver

[sodatea]

semver 打错了……

[lincanbin]

如果换API，我会选择让旧App全部挂掉，爱升不升——个人项目。

[luin]

没仔细看不好意思，以为你问的是接口层面 T_T

[lijingyu68]

我最近也在纠结这个问题

[coosir]

@sodatea semver只是版本命名方式吧。我比较困惑的是代码怎么更好地去组织

[flyingfz]

我们之前的处理方式是，每个版本都部署一个虚拟目录，这里是IIS的说法。但ngnix之类的，可以使用urlRewrite方式模拟。
总之，就是每个版本的api，就是一个独立的站点，独立运作，互不影响。

[konakona]

@flyingfz 如此一来，需要维护的项目就*N 了..当然是避免不了，但是有没有办法在一个项目里维护呢？

如果是按照多项目来维系版本共存的话。依赖一个 GIT 倒是个不错的办法，比如说 GIT 有一个 branch 叫“ api ”的目录。里面一堆 v1~vn_release 的 branch 么..