客戶端開發介面向前兼容策略是如何的？

01-05

我的問題是這樣的，一般的ios android端的軟體屬於前端，後端連接介面伺服器，無法避免的需要版本升級，且新舊版本需要共存，同時提供服務，ios app商店需要審核，審核可能會測試一下軟體，所以要有對應的介面可以訪問。
在這幾個前提下，一般伺服器介面是如何保證向前兼容的（有時候數據結構會大改，導致之前版本無法使用），還有ios 和android端的更新上架策略（上架順序）是怎樣的，希望指導一下。

設計伺服器介面時，最開始就定義一個錯誤碼 NotImplemented, 表示介面沒有實現。客戶端遇到這個錯誤碼，可以根據實際情況進行處理，比如提示軟體需要升級。

每一個介面，都帶版本號。比如用戶登陸介面第 1 版為

/1/user/login

返回 Json 數據。數據結構改動後，假如 Json 數據只是增加欄位，這時介面不用修改。當登陸介面改動太大，會刪除或者修改欄位。就遞增版本號，新添介面：

/2/user/login

舊的 /1/user/login 介面需要保留。這時舊的客戶端使用 /1/user/login，而新的客戶端使用 /2/user/login。在服務端 /1/user/login 和 /2/user/login 進行重構，某些地方調用相同的代碼。

兩個介面並存一段時間後，比如過了 3 個月。估計舊的客戶端差不多都升級到新的了，這時舊的 /1/user/login 介面就可以不再維護，直接返回 NotImplemented 錯誤碼。

封裝複雜，介面簡單。

說說常見的幾個解決方案：

1、一個前端版本對應一個後端版本，很多可以做到自動化處理的，當然，有的就很難處理，如.net。

2、資料庫的結構採取只增不刪不改。

3、存儲過程資料庫函數根據版本號命名，按版本新增。

APP要獲取版本的信息，了解各版本的使用率。

最重要的，版本一定要有分支，有歷史記錄，隨時可以找到當時的版本修改發布。

先說一下版本控制，在業務邏輯主體裡面，要根據請求的客戶端類型版本信息，返回不同的內容，做到一個介面能完好的輸出業務信息。客戶端版本更新後，伺服器代碼是保持增量修改的。伺服器版本控制的寫法很多，就像app要支持本地老版本留下的數據一樣，方法很多。

然後說一下數據大改的問題。數據大改一般也就是改業務代碼的數據結構了。如果不涉及資料庫的修改，必須新開介面。如果資料庫也有變動，則必須廢棄老介面以保證安全性。廢棄老介面可以通過通用的介面數據返回error code，app根據特定error code提示升級。

傳輸的json對象盡量增加欄位，而不是刪除已有或者改動已有，這樣就會繼續向前兼容數據結構

上架，ios會慢一點，安卓倒是無所謂，不過現在各大第三store也要求審核了，且很嚴格，可以同時申請，哪個過了就帶來量，不存在說非要一起上的情況

有一個好用的後台介面管理平台很重要！！！

將所有介面統一管理到一個域名下，每個介面由域名、app標示、業務作用域、對應功能介面名、介面版本號，如

https:/ / api.com/ cn.edu.zafu /config /getConfig /1.0

當介面發升大改時，只需改變介面版本號即可。

數據結構大改動，當然是另開新介面啊，舊的介面仍然保留就好了。