APP接口版本不兼容怎么辦？教你一招

現(xiàn)在基本每個(gè)公司都做APP，所以大家都面臨 APP接口版本兼容的問題。

iOS和android 要不斷開發(fā)新版本，很多服務(wù)端開發(fā)都是在以前接口的邏輯上進(jìn)行修改。新的APP和接口開發(fā)后，接口如何兼容老的APP？

有的公司每次發(fā)布完APP，就強(qiáng)制用戶更新到最新版本。不推薦這樣，因?yàn)橛脩趔w驗(yàn)太差。

就算是用強(qiáng)制更新，在蘋果審核期間，新的APP接口和老的接口也必須能同時(shí)使用。

下面我們說下如何做，大家有不同意見可以留言討論。

一、客戶端做兼容，接口不用做兼容

1、APP強(qiáng)制更新（不建議）

接口URL：api.xxx.com/v1.0/xxxx.java

接口的URL中加入版本號(hào)，如上：v1.0。

每次發(fā)布新APP版本就強(qiáng)制更新。

灰度服務(wù)器部署正在審核中的接口版本（如：v1.1）。等審核通過后，將老版本的APP設(shè)置強(qiáng)制更新，這樣老的接口就不用了。

然后把線上服務(wù)器重新部署上最新的代碼，再去掉灰度服務(wù)器。

這樣APP接口全部訪問正式的線上服務(wù)器。

2、熱更新

緊急的小需求可以用熱更新，大的需求建議還是用原生的代碼，因?yàn)槟阌脽岣滦薷耐辏ㄓ肑S或Lua），最后還要在原生代碼里修改。

網(wǎng)游用熱更新的比較多，因?yàn)榫W(wǎng)游的APP太大，不可能加個(gè)小關(guān)卡就要求用戶重新下載，并且游戲更新比企業(yè)級(jí)APP更頻繁，用熱更新可以不斷新加關(guān)卡、場(chǎng)景、活動(dòng)推廣。

3、React Native 和Weex

Weex比React Native好用，建議大家可以嘗試下。個(gè)人建議先不要大范圍用它們來做，畢竟它們只是第三方的東西，有的東西也不太完善。

二、服務(wù)端做版本兼容

全部接口版本是否統(tǒng)一：

所有的接口都用相同的版本號(hào)：這樣要發(fā)一個(gè)APP新版本就統(tǒng)一修改版本號(hào)，好修改，但是如果想修改其中一個(gè)接口的版本號(hào)就不行了。

每個(gè)接口的版本號(hào)可以不一樣：這樣比較靈活，建議這樣做。

因?yàn)橐呀?jīng)好多年沒有做過服務(wù)端了。下面的見解如果有錯(cuò)誤，希望指正。

1、每個(gè)接口邏輯里加if 判斷（不建議）

接口URL：api.xxx.com/api？version=v1&.。

if （version == ‘1.5.0’） {

do_something

} else if （version ==‘1.4.0‘） {

do_something

}

優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單

缺點(diǎn)：不同版本的邏輯都在一個(gè)方法里，在于容易造成代碼混亂，不利于維護(hù)。

2、不同的文件夾

相當(dāng)于每個(gè)接口版本都是一個(gè)獨(dú)立的項(xiàng)目。放到服務(wù)器的獨(dú)立文件夾里。

例如：

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

文件夾位置：Controller/V1.0/

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

文件夾位置：Controller/V2.1/

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

優(yōu)點(diǎn)：版本邏輯分開維護(hù)。看url就能知道哪個(gè)版本。刪除多余版本不用修改代碼。

缺點(diǎn)：同個(gè)接口不同版本文件是重復(fù)的。并且如果有個(gè)接口前幾版就有問題，一直遺留到現(xiàn)在，就需要改好幾套一樣的代碼。

3、不同版本用不同的方法：

類似：

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

class XXXX{

public functionV1_0（） { }

public functionV2_0（） { }

}

java或者C# 都有路由配置，可以用路由配置不同版本的URL跳轉(zhuǎn)到不同的方法里。

4、用繼承的方式

“一瓶真情”在評(píng)論中回復(fù)：采用繼承的方式，既可以利用之前的接口代碼，又可以采用override的方式修改部分接口的實(shí)現(xiàn)。

這樣是可以的。但是如果你上個(gè)版本（也就是父類）修改了代碼，就會(huì)影響后面的所有版本。

在線上有bug或者需求變更的時(shí)候很可能會(huì)修改基類。

大家可以討論下。

5、部署到不同的服務(wù)器

“xuanbg”在評(píng)論中回復(fù)：

不同版本不同分支，部署在不同的服務(wù)器上。如果某個(gè)版本用不到了，直接干掉服務(wù)就好了。

例如我現(xiàn)在的API要從1.x升到不兼容的2.0版本了，那就給當(dāng)前的發(fā)布分支打個(gè)Tag。等哪天1.x版的API需要fix bug，就能很簡(jiǎn)單地從這個(gè)Tag切一個(gè)1.x的分支出來fix bug后進(jìn)行測(cè)試發(fā)布，而且這個(gè)分支不會(huì)合并到任何分支，所以不會(huì)影響其他版本。

這個(gè)方案不好的地方在于，如果2.0也有同樣bug的話，也要在2.0分支上改一遍。如果版本很多的話，這活就不好干了。所以呢，一般不會(huì)同時(shí)發(fā)布兩個(gè)以上的版本，在升級(jí)不兼容的第三個(gè)版本前，一定會(huì)把第一個(gè)版本干掉。

但是比如淘寶、微信，有的時(shí)候忘記更新了，你會(huì)發(fā)現(xiàn)淘寶已經(jīng)升級(jí)過4、5個(gè)版本了，然后老版本還能用。也就是有的APP確實(shí)需要兼容4、5個(gè)版本。

另外，如果要兼容過多的版本，服務(wù)器也需要夠多才行。同時(shí)，因?yàn)槔习姹镜娜擞玫纳伲簿褪怯械姆?wù)器訪問量很少，有的服務(wù)器訪問量很多。不能真正的負(fù)載均衡，浪費(fèi)了服務(wù)器資源。

6、混合使用

“ Tokyo^hot”在回復(fù)中說到兩種方式的混合使用。服務(wù)端的幾種方法混用：

6.1、第3種和第4種方法一起用。先用繼承，如果新版本和以前的版本無法復(fù)用，就用路由設(shè)置新的方法。

6.2、第1種方法和第3中方法一起用，簡(jiǎn)單的小改動(dòng)用第1種，加個(gè)if判斷。改動(dòng)較大的用第3種，新開個(gè)方法。