APP API需要同時維護多個版本如何優雅的設計？

第一種形式：

Controller/V1.0.0/
-----------------/UserController.php
-----------------/UploadController.php
-----------------/********************
Controller/V2.1.0/
-----------------/UserController.php
-----------------/UploadController.php
-----------------/********************

第二種形式

Controller/
----------/UserCreateController.php
----------/UserInfoController.php
----------/UploadImageController.php
UserCreateController.php 內容如下

更多，請回答

回複內容：

第一種形式：

Controller/V1.0.0/
-----------------/UserController.php
-----------------/UploadController.php
-----------------/********************
Controller/V2.1.0/
-----------------/UserController.php
-----------------/UploadController.php
-----------------/********************

第二種形式

Controller/
----------/UserCreateController.php
----------/UserInfoController.php
----------/UploadImageController.php
UserCreateController.php 內容如下

更多，請回答

如果只是討論的話：

第三種

用戶端在做請求的時候在介面中添加ver欄位，標識出請求的是哪個介面：

• api.xxx.com/api?ver=v1&...
• api.xxx.com/api?ver=v2&...

這種做起來比較簡單也容易理解，但是在你的每個介面邏輯裡面都得需要寫判斷版本的代碼了。比如

if ver == 'v1':  do_something_with_v1_styleelif ver == 'v2':  do_something_with_v2_style

這樣的代碼看起來感覺很不舒服。

第四種

用戶端在做請求的時候在HTTP HEAD裡面中添加API-VERSION欄位，標識出請求的是哪個介面：

• -H "API-VERSION: v1"
• -H "API-VERSION: v2"

這個需要統一做的事情稍微有點多，但之後的介面邏輯會比較好些。在入口的地方擷取介面版本，然後把請求分發到對應版本的介面處理器上。

api(req):  if req.HEADS["API-VERSION"] == 'v1':    distribute_to_v1_api(req)  elif ver == 'v2':    distribute_to_v2_api(req)

第五種

不同版本使用不同的網域名稱，這樣：

• v1.api.xxx.com
• v2.api.xxx.com

網域名稱的方式可以採用下面的兩種方式：
1、不同版本的api部署成不同的應用（甚至可以部署到不同的伺服器上），彼此間獨立，其好處是部署的過程不會影響其他版本api的使用，並且可以減輕單台伺服器的負擔。
2、部署在一個應用上面，但是和第四種一樣，在介面入口出分發到不同版本的介面處理器上進行處理。好處是不同版本間能夠直接複用相同的功能。

最後說一下吧

我個人比較傾向於網域名稱方式或者你的第一種(xxx.com/v1/、xxx.com/v2/)：

• 在整個產品的生命週期中介面的數目和功能可能會不停的增加，但對於某個介面而言，不會頻繁的變動（修改介面的輸入輸出約定），而增加介面對於老的介面是沒有影響的，也就不會到必須升級介面的地步（你的老app只是在用原來就存在的老介面而已，新增加的介面對它沒有影響）；
• 如果你的介面變化已經到了今天v1、明天v2、後天v3的地步，那麼得考慮你們一開始對產品的需求是否足夠準確了（估計需要維護的介面文檔也會讓人頭疼）；
• 不同版本介面相互獨立在某種程度上限制了你，讓你不會隨隨便便就v1、v2、v3。（當你每天都要用一個新網域名稱的時候你自己一定會不自然的反思是不是變換太頻繁了）；
• 介面版本資訊能夠直接在url裡面體現，清晰易懂，也比較容易做介面調試（沒錯，給我一個Chrome就夠了）；
• 不同的版本的api應用（或者介面處理器）之間彼此獨立，這符合軟體工程的低耦合原則。

沒有很優雅的設計，只能自己考慮的長遠寫，介面的代碼寫的可擴充性高一些。App跟網站不一樣，即使你發新版了還是有很高几率使用者不買賬不更新的。所以最好在最初設計介面的時候就想的長遠些，API的URL不能隨便動， 可以讓手機端在請求介面的時候給你在參數中掛一個版本號碼，這樣能區分出用戶端的版本，但即使是這樣搞多了代碼寫起來也很坑的， 所以設計核心業務的API只能考慮的比較清楚了，有些東西剛開始不做但是近期幾個版本要做的話就預先留好入口，代碼寫的可擴充性高一些方便以後相容，資料庫中也可先預留好欄位。

產品最初兩版基本上都在探路，方向調整和邏輯重構是難免的，說下切身體會:痛苦的把API做了向前相容（判斷介面通訊時新加的參數，沒有就給預設值，有些欄位值，可以靠查老資料算出來等等），測試新舊用戶端訪問都沒問題後然後半夜4點爬起來（因為看友盟分析4點是我們產品活躍最少的時候，基本沒人）改正式環境的資料庫、往新表裡跑資料。當時App已經有一萬多使用者了，白天日活還說的過去。跑著跑著發現突然有個使用者在四點半的時候過來用App還產生了些資料...當時感覺有萬匹草泥馬從我的小心臟上踏過，趕緊把DNS解析先暫停了， 等一切都弄後再恢複回來的。

PS:說句題外話，有一個不知名的渠道抓了我們的APK包，結果他們SEO做的還挺好，百度搜我們產品的關鍵字他們總是排得挺靠前，氣人的是丫抓了我們1.3版本的包後半年不更新，現在我們都2.0.2了，現在在新增使用者中都能看到1.3版本註冊進來的使用者... 從這能看出安卓App的版本更新有多難控制(在產品不強的時候不敢讓使用者強制更新，安卓除了小米那一派程式都不能進行靜默更新)

