APP接口版本不兼容怎么办? 教你一招

  如今基本每一个公司都作APP,因此你们都面临 APP接口版本兼容的问题。php

  iOS和android 要不断开发新版本,不少服务端开发都是在之前接口的逻辑上进行修改。新的APP和接口开发后,接口如何兼容老的APP?java

  有的公司 每次发布完APP,就强制用户更新到最新版本。不推荐这样,由于用户体验太差。android

  就算是用 强制更新,在苹果审核期间,新的APP接口和老的接口也必须能同时使用。api

  下面咱们说下如何作,你们有不一样意见能够 留言讨论。服务器

  1、客户端作兼容,接口不用作兼容

  一、APP强制更新(不建议)微信

  接口URL:api.xxx.com/v1.0/xxxx.java负载均衡

  接口的URL中加入版本号,如上:v1.0。ide

  每次发布新APP版本就强制更新。测试

  灰度服务器部署正在审核中的接口版本(如:v1.1)。等审核经过后,将老版本的APP设置强制更新,这样老的接口就不用了。url

  而后把线上服务器从新部署上最新的代码,再去掉灰度服务器。

  这样APP接口所有访问正式的线上服务器。

  二、热更新

  紧急的小需求能够用热更新,大的需求建议仍是用原生的代码,由于你用热更新修改完(用JS或Lua),最后还要在原生代码里修改。

  网游用热更新的比较多,由于网游的APP太大,不可能加个小关卡 就要求用户从新下载,而且游戏更新比企业级APP更频繁,用热更新能够不断新加关卡、场景、活动推广。

  三、React NaTIve 和Weex

  Weex比React NaTIve好用,建议你们能够尝试下。我的建议先不要 大范围用它们来作,毕竟它们只是第三方的东西,有的东西也不太完善。

  2、服务端作 版本兼容

  所有接口版本是否统一:

  全部的接口都用相同的版本号:这样要发一个APP新版本就统一修改版本号,好修改,可是若是想修改其中一个接口的版本号就不行了。

  每一个接口的版本号能够不同:这样比较灵活,建议这样作。

  下面的看法若是有错误,但愿指正。

  一、每一个接口逻辑里加if 判断(不建议)

  接口URL:api.xxx.com/api?version=v1&.。

  if (version == ‘1.5.0’) {

    do_something

  } else if (version ==‘1.4.0‘) {

    do_something

  }

  优势:实现简单

  缺点:不一样版本的逻辑都在一个方法里,在于容易形成代码混乱,不利于维护。

  二、不一样的文件夹

  至关于每一个接口版本都是一个独立的项目。放到服务器的独立文件夹里。

  例如:

  接口URL:api.xxx.com/v1.0/xxxx.php

  文件夹位置:Controller/V1.0/

  -----------------/xxxx.php

  文件夹位置:Controller/V2.1/

  -----------------/xxxx.php

  优势:版本逻辑分开维护。看url就能知道哪一个版本。删除多余版本 不用修改代码。

  缺点:同个接口不一样版本文件是重复的。而且若是有个接口前几版就有问题,一直遗留到如今,就须要改好几套同样的代码。

  三、不一样版本用不一样的方法 :

  相似:

  接口URL:api.xxx.com/v1.0/xxxx.php

  class XXXX{

    public funcTIonV1_0() { }

    public funcTIonV2_0() { }

  }

  java或者C# 都有路由配置,能够用路由配置不一样版本的URL跳转到不一样的方法里。

  四、用继承的方式

  “一瓶真情”在评论中回复:采用继承的方式,既能够利用以前的接口代码,又能够采用override的方式修改部分接口的实现。

  这样是能够的。可是若是你上个版本(也就是父类)修改了代码,就会影响后面的全部版本。

  在线上有bug或者需求变动的时候极可能会修改基类。

  你们能够讨论下。

  五、部署到不一样的服务器

  “xuanbg”在评论中回复:

  不一样版本不一样分支,部署在不一样的服务器上。若是某个版本用不到了,直接干掉服务就行了。

  例如我如今的API要从1.x升到不兼容的2.0版本了,那就给当前的发布分支打个Tag。等哪天1.x版的API须要fix bug,就能很简单地从这个Tag切一个1.x的分支出来fix bug后进行测试发布,并且这个分支不会合并到任何分支,因此不会影响其余版本。

  这个方案 很差的地方在于,若是2.0也有一样bug的话,也要在2.0分支上改一遍。若是版本不少的话,这活就很差干了。因此呢,通常不会同时发布两个以上的版本,在升级不兼容的第三个版本前,必定会把第一个版本干掉。

  可是好比 淘宝、微信 ,有的时候忘记更新了,你会发现淘宝已经升级过四、5个版本了,而后老版本还能用。也就是有的APP确实须要兼容四、5个版本。

  另外,若是要兼容过多的版本,服务器也须要够多才行。同时,由于老版本的人用的少,也就是有的服务器访问量不多,有的服务器访问量不少。不能真正的负载均衡,浪费了服务器资源。

  六、混合使用

  “ Tokyo^hot”在回复中说到两种方式的混合使用。服务端的几种方法混用:

  6.一、第3种和第4种方法一块儿用。先用继承,若是新版本和之前的版本没法复用,就用路由设置新的方法。

  6.二、第1种方法和第3中方法一块儿用,简单的小改动用 第1种,加个if判断。改动较大的用 第3种,新开个方法。

  3、结尾

  若是你们有什么好办法,能够留言,谢。

  接口兼容其实主要是服务端的任务。APP的工做量相对简单。

  你们都是怎么作的?

相关文章
相关标签/搜索