后端自动化版本管理，再也不用改URL了！_.NET

您所在的位置：程序员俱乐部 > 编程开发 > .NET > 后端自动化版本管理，再也不用改URL了！

后端自动化版本管理，再也不用改URL了！

2017/11/22 10:04:39 孤独的探索号程序员俱乐部我要评论(0)

摘要：每次升级接口版本时，后端、前端、客户端都是痛苦的：后端：要兼容旧版客户端，以前的接口不能动啊，又得写新接口、新文档了，唉！前端：还好，就是版本号到处都是，改起来比较烦。Android：快点啊产品催需求呢，服务器别停太久。对了你知道编译一次要多久么？泪奔。。。前端：对对，别停太久。还有文档别再写错了啊，上次你复制粘贴的v3害我接口调了半天，原来是v4。。。iOS：我也被坑了。。。后端：呃，我尽快，写文档会注意的哈。后端：另外旧域名http://api.aaa.com/v4也会一直开着
标签：URL 版本

每次升级接口版本时，后端、前端、客户端都是痛苦的：

后端：要兼容旧版客户端，以前的接口不能动啊，又得写新接口、新文档了，唉！

前端：还好，就是版本号到处都是，改起来比较烦。

Android：快点啊产品催需求呢，服务器别停太久。对了你知道编译一次要多久么？泪奔。。。

前端：对对，别停太久。还有文档别再写错了啊，上次你复制粘贴的 v3 害我接口调了半天，原来是 v4 。。。

iOS：我也被坑了。。。

后端：呃，我尽快，写文档会注意的哈。

后端：另外旧域名 http://api.aaa.com/v4 也会一直开着，保证不会像上次那样让3.0客户端请求挂的。

后端：@前端对了，你们用一个全局的 BASE_URL 存起来，以后改一个地方就好了。

Android：我们就是这么干的嘿嘿！

iOS：我们也是，还是我封装的。

iOS：但问题是往往多个接口版本并存，还是要写好几个BASE_URL，我们这是从BASE_URL_V2到BASE_URL_V4。

Android：唉，这个就没办法了。

前端：我们现在也是这么做的，但之前的那家伙没封装啊，写得到处都是。。。

后端：周哥，升级接口版本好烦啊，你有什么好的办法吗？

周哥：具体说下你的问题。

后端：每次都要写新的接口和文档，服务器也要重启，前端和客户端总是抱怨改域名和文档错误。

项目很赶，文档是复制粘贴的，总是会落下某些地方没改。

但是不复制粘贴吧，你看看这格式，重新写实在是太麻烦了！

周哥：哈哈，以前我们也总是碰到这种问题，现在解决了。试试这个

周哥：https://github.com/TommyLemon/APIJSON

后端：哇，居然还有这么厉害的后端框架啊！我只用过SSH。

周哥：我也是上个月才知道的，朋友推荐的，我试了一周，非常好用，也没啥大的问题，就整到项目中了。

周哥：SSH太重了，老项目中APIJSON主要用来实现新接口，新项目就只用APIJSON了。

后端：可以的。不过它怎么解决版本问题呢？文档里没说啊。

周哥：写在最下面了。 http://39.108.143.172/

后端：可在最外层传版本version来指定使用的版本，不传或 version <= 0 则使用最新版。？？

周哥：描述确实比较简单，我就问了下作者，他是这么说的：

TommyLemon:

可以在请求时传入一个version来指定使用的接口版本号，例如查询用户隐私信息：

URL: http://39.108.143.172:8080/gets

表单:

{
    "Privacy": {
        "id": 82001,
        "_password": "123456"
    },
    "tag": "Privacy",
    "version": 1
}

而且只需要登录时传一个全局默认version，之后所有需要登录的接口(一般占绝大部分)就都默认用这个了。

{
    "type": 0,
    "phone": "13000082001",
    "password": "123456",
    "version": 1
}

所以查询用户隐私信息就可以省略version了：

{
    "Privacy": {
        "id": 82001,
        "_password": "123456"
    },
    "tag": "Privacy"
}

因为上面传的version和全局默认version一样，所以服务器返回的结果都一样：

{
    "Privacy": {
        "id": 82001,
        "certified": 1,
        "phone": 13000082001,
        "balance": 8067
    },
    "code": 200,
    "msg": "success"
}

当然如果某个请求需要用到和全局默认version不一样的接口，也可以指定当前的version：

{
    "Privacy": {
        "id": 82001,
        "_password": "123456"
    },
    "tag": "Privacy",
    "version": 2
}

由于第2版接口改了校验配置，所以返回结果就不一样了：

{
    "Privacy": {
        "id": 82001,
        "_password": "123456"
    },
    "code": 406,
    "msg": "Privacy不允许传 _password 等[_password, _payPassword]内的任何字段！"
}

注：这个接口需要登录权限，请先点击右上角登录后再请求。

APIJSON在线测试

周哥：我照着这个来，在测试网页一个个试了，确实是这样的。

后端：但还有个问题，项目中可能多个版本并存，它是不是也要同时维护多个版本啊？

周哥：哈哈，以前只有两种做法：

1.前端根据的需求调对应版本的api，后端只新增对应新需求的api。

2.前端只用一个版本，后端对新版不需要改的api v2也提供一个对应新版的api v3，然后和v2一样处理，可以提取v2的代码为一个公共的函数。

或者就干脆重定向到v2，这个操作简单些，但要损失一些性能。

周哥：用APIJSON就只需要把原来旧版的api改下版本号version为一个统一的最新版，请求中传的version如果不存在，则会自动转到比它高的最接近版本。

后端：也就是我把v1,v2都改成v3，然后前端传v1或v2过来，它就转到v3了？如果不改的话还是转到v2？

周哥：对的。如果不传version或version<=0，就会强制用最新版。这个在修复某些api漏洞时很有用，把前端请求中的version去掉或者改成0，就可以了。

后端：我觉得可以直接把api的version改成最新版，这样更简单。