你是怎么管理后端的接口版本的

[cevincheung]

后端接口版本一多，管理好像特别麻烦

比如请求地址如下：/v1/user/login, /v2/user/login

现在的是方案是：

<?php
class user...
class v1_user extends user...


if (!class_exists($vClass)) $cn = 'base';
else $cn =& $vClass;

$result = call_user_func(array($cn, $method));
echo do($result);

[huigeer]

你们这版本迭代这这么弄的么？ 好蛋疼，

[cevincheung]

@huigeer
求优化方案- -#

[kqz901002]

@cevincheung git svn 继承

[cevincheung]

@kqz901002

访问的URL不变。变的只是版本啊…… 现在是rewrite到index.php 然后获取版本，取class名字，如果没有定义指定版本的class就调用base版。

你意思是每个版本都是独立目录？

[learnshare]

用 url 区分版本真的好么？不应该是接口自己升级，尽量不影响客户端么

[cevincheung]

@learnshare
现在是没影响啊。旧的版本没人动的。新版本发布后只是在controller目录里增加一个vn的目录而已。旧的被废弃的接口在入口就直接ban掉请求了。

[kqz901002]

@cevincheung 旧的可以用git做tag啊

[sectic]

给app的借口最好带有版本

[siteshen]

暂时没有加入版本的概念，只是实现API时，尽量做到向后兼容。实在遇到不兼容时，加入下面的代码：

if (version <= 1.5.4) {
return 1.5;
} else {
return 2;
}

[tabris17]

这些版本都是同时使用的？

[cevincheung]

@tabris17 嗯，同时在使用的，因为app的第一版后会逐渐增多一些功能而且同一功能不同版本可能输出的结构不同

@siteshen 你懂了- -#
@sectic 就是这样啊

[tczzjin]

在nginx层url重定向到目录吧,v1目录和v2目录都维护一套完整的api接口,
最好不要再class名字上做文章,管理起来很奇怪,也不利于ide解析生成文档啥的

[Actrace]

单独两套接口的意义是在以后你会降低维护成本。
一个接口多版本的意义是装哔。。。

[ipconfiger]

如果V2 的接口不存在就自动去V1去取数据就ok了，自动降级处理

[tabris17]

如果V1和V2的请求数据和返回数据格式不一样那就应该当作两个接口来处理

[huigeer]

版本： branch -> trunk -> prepareonline -> online

[kukat]

namespace

[liuweisj]

后端跑多个版本的项目， project-v1 , project-v2 用nginx 把http://host:[prot]/v1/query 的upstream配置到 project-v1的地址 ，http://host:[prot]/v2/query 的upstream配置到 project-v2的地址

[yueyoum]

做过这方面工作，当时是在url上做文章，后来一想，还是在 http request header 上弄比较好，不过原理是一样的：

url 或者 header 带版本信息

nginx 根据 url 或者 header 来分发请求

ver1 -> app1
ver2 -> app2

如果数据库改动太大，确实很难兼容的时候， 就版本客户端不让登录，强制升级

[yueyoum]

@cevincheung

>> 你意思是每个版本都是独立目录？

我是这个意思， 见上面解释

比如 已经部署了 web/myweb/
然后升级到了 v2， 但以前的还要保留
那么 就 把v2 部署到 web/myweb-v2

也就是此时起了两个 web服务， 然后用nginx转发吧