标签:行修改 发布 自己 设置 修改 实现 control 推广 位置
现在基本每个公司都做APP,所以大家都面临 APP接口版本兼容的问题。
iOS和android 要不断开发新版本,很多服务端开发都是在以前接口的逻辑上进行修改。新的APP和接口开发后,接口如何兼容老的APP?
有的公司 每次发布完APP,就强制用户更新到最新版本。不推荐这样,因为用户体验太差。
就算是用 强制更新,在苹果审核期间,新的APP接口和 老的接口 也必须能同时使用。
下面我们说下如何做,我们用的是最后一种方式,大家有不同意见可以 留言讨论。
一、客户端 做兼容,接口不用做兼容
1、APP强制更新(不建议)
接口URL:api.xxx.com/v1.0/xxxx.java
接口的URL中加入版本号,如上:v1.0。
每次发布新APP版本就强制更新。
灰度服务器 部署正在审核中的 接口版本(如:v1.1)。等审核通过后,将老版本的APP设置强制更新,这样老的接口就不用了。
然后把线上服务器重新部署上最新的代码,再去掉灰度服务器。
这样APP接口全部访问正式的线上服务器。
2、热更新
紧急的小需求可以用热更新,大的需求建议还是用原生的代码,因为你用热更新修改完(用JS或Lua),最后还要在原生代码里修改。
网游用热更新的比较多,因为网游的APP太大,不可能加个小关卡 就要求用户重新下载,并且游戏更新比企业级APP更频繁,用热更新可以不断新加关卡、场景、活动推广。
3、React Native 和Weex
Weex比React Native好用,建议大家可以尝试下。个人建议先不要 大范围用它们来做,毕竟它们只是第三方的东西,有的东西也不太完善。
二、服务端 做 版本兼容
全部接口版本是否统一:
所有的接口都用 相同的版本号:这样要发一个APP新版本就统一修改版本号,好修改,但是如果想修改其中一个接口的版本号就不行了。
每个接口的版本号可以不一样:这样比较灵活,建议这样做。
因为已经好多年没有做过服务端了。下面的见解如果有错误,希望指正。
1、每个接口逻辑里 加if 判断(不建议)
接口URL:api.xxx.com/api?version=v1&..
if (version == ‘1.5.0’) { do_something } else if (version ==‘1.4.0‘) { do_something }
优点:实现简单
缺点:不同版本的逻辑都在一个方法里,在于容易造成代码混乱,不利于维护。
2、不同的文件夹
相当于每个接口版本都是一个独立的项目。放到服务器的独立文件夹里。
例如:
接口URL:api.xxx.com/v1.0/xxxx.php
文件夹位置:Controller/V1.0/
-----------------/xxxx.php
文件夹位置:Controller/V2.1/
-----------------/xxxx.php
优点:版本逻辑分开维护。看url就能知道哪个版本。删除多余版本 不用修改代码。
缺点:同个接口不同版本 文件是重复的。并且 如果有个接口前几版就有问题,一直遗留到现在,就需要改好几套一样的代码。
3、不同版本 用不同的方法 :
类似:
接口URL:api.xxx.com/v1.0/xxxx.php
class XXXX{ public functionV1_0() { } public functionV2_0() { } }
java或者C# 都有路由配置,可以用路由配置不同版本的URL跳转到不同的方法里。
三、结尾
自己 已经有好几年没做 服务端了。如果大家有什么好办法,可以留言,谢。
接口兼容其实主要是服务端的任务。APP的工作量相对简单。
大家都是怎么做的?
标签:行修改 发布 自己 设置 修改 实现 control 推广 位置
原文地址:http://www.cnblogs.com/dahe007/p/6255401.html