電子發燒友App
現在基本每個公司都做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更頻繁，用熱更新可以不斷新加關卡、場景、活動推廣。
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跳轉到不同的方法里。
4、用繼承的方式
“一瓶真情”在評論中回復：采用繼承的方式，既可以利用之前的接口代碼，又可以采用override的方式修改部分接口的實現。
這樣是可以的。但是如果你上個版本（也就是父類）修改了代碼，就會影響后面的所有版本。
在線上有bug或者需求變更的時候 很可能會修改基類。
大家可以討論下。
5、部署到不同的服務器
“xuanbg”在評論中回復：
不同版本不同分支，部署在不同的服務器上。如果某個版本用不到了，直接干掉服務就好了。
例如我現在的API要從1.x升到不兼容的2.0版本了，那就給當前的發布分支打個Tag。等哪天1.x版的API需要fix bug，就能很簡單地從這個Tag切一個1.x的分支出來fix bug后進行測試發布，而且這個分支不會合并到任何分支，所以不會影響其他版本。
這個方案 不好的地方在于，如果2.0也有同樣bug的話，也要在2.0分支上改一遍。如果版本很多的話，這活就不好干了。所以呢，一般不會同時發布兩個以上的版本，在升級不兼容的第三個版本前，一定會把第一個版本干掉。
但是比如 淘寶、微信 ，有的時候忘記更新了，你會發現淘寶已經升級過4、5個版本了，然后老版本還能用。也就是有的APP確實需要兼容4、5個版本。
另外，如果要兼容過多的版本，服務器也需要夠多才行。同時，因為老版本的人用的少，也就是有的服務器訪問量很少，有的服務器訪問量很多。不能真正的負載均衡，浪費了服務器資源。
6、混合使用
“ Tokyo^hot”在回復中說到兩種方式的混合使用。服務端的幾種方法混用：
6.1、第3種和第4種方法一起用。先用繼承，如果新版本和以前的版本無法復用，就用路由設置新的方法。
6.2、第1種方法和第3中方法一起用，簡單的小改動用 第1種，加個if判斷。改動較大的用 第3種，新開個方法。
三、結尾
自己 已經有好幾年沒做 服務端了。如果大家有什么好辦法，可以留言，謝。
接口兼容其實主要是服務端的任務。APP的工作量相對簡單。
大家都是怎么做的？
工商網監
評論