上篇寫《聊聊資料庫和快取同步機制》的時候，收到一份讀者留言，希望我來談談API開發過程中的版本控制。這是一個很好的話題，對於任何網際網路產品，隨著需求的改進，都會遇到同樣的問題，我自己也被這個問題困擾過。所以今天我嘗試來做一個總結，將我過去不同專案中遇到的API版本控制方案羅列出來，給大家做一個參考，希望對朋友們有所幫助。
API版本控制模式
首先我們先談談，API的版本控制的3種模式：
1. 不設定版本模式
意味著每個API只提供一個版本，如果要修改本API, 所有的使用者都必須使用最新的API，任何API的修改都會影響到所有的使用者。
2.API自帶版本模式
同一個名稱的API可以建立多個版本，API呼叫方根據自己的需求選擇使用對應的API版本。新版本與老版本共存，意味著老版本使用者不會受新版本更新的影響。
3. 相容性版本模式
每個API只有一個版本，API需要相容以前老版本API的功能。所有版本使用者都呼叫同一個API，通過內在程式碼保證相容性。
從實戰看，單純使用模式1的情況會比較少，主要使用模式2或者模式3。
API版本控制的執行方案
對於上文提到的3種版本控制模式，接下來，我們來講講如何來落地執行每種模式：
無版本模式的可選執行方案
新功能直接在老API上修改，強制呼叫方客戶端（iOS/Android/H5）升級，使用者體驗會受到影響，也有一定的技術難度，適用場景比較有限。
更換API名稱，新功能使用新的API名字，新版本客戶端呼叫新名稱API，例如：
http://jiagouzhan.com/api/user/login
http://jiagouzhan.com/api/user/newLogin
API自帶版本模式的可選執行方案
1. URI上新增版本號，URI中直接標記使用的是哪個版本，無版本號URI預設使用最新版本。
http://jiagouzhan.com/api/user/list
http://jiagouzhan.com/api/v2/user/list
2. 引數帶版本號，即在每個API請求後新增一個version引數，表示請求的是哪個版本。
http://jiagouzhan.com/api/user/list?Version=2
相容性版本模式的可選執行方案
基於版本模式的改進方案，將版本從API中“隱藏”起來。
通過HTTP頭部做版本指定
在處理API請求的時候，服務端根據API呼叫方在request header中設定的api-version來判斷，進而執行不同的邏輯處理分支，如以下所示，以此實現版本的相容性。
GET http://jiagouzhan.com/api/user/list
Host: jiagouzhan.com
Cache-Control: no-cache
Referer: http://download.google.com/
User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-
api-version: v1
2. 通過客戶端token進行控制
客戶端與服務端互動的時候，都會有一個token欄位，我們選擇在token上“做文章”，服務端實現一個token處理器，用於token與版本的對映，具體的步驟如下：
http://jiagouzhan.com/api/user/list?token=5782b5e0512c7d47345d10af413b3d28
-----> 服務端token處理器處理 ------> 確定請求API的內部版本 -----> 執行具體API ------>返回結果
這樣做，有兩個明顯的好處：
1. 在一定程度上防止了很多無效的請求，如果使用的是https傳遞資訊，就更安全了，阻止外部攻擊者利用API請求攻擊服務端，由於拿不到token, 即便清楚API的介面名稱和路徑，也根本無法突破API閘道器，到達服務內部。
2. 服務端可以靈活的配置介面，客戶端只要每次請求的時候帶上預設的token引數，就可以得到客戶端想要的了，完全不需要關心版本的問題，對版本做到透明。
對API版本控制方案的描述告一段落了，明眼人心裡一定清楚我推薦使用那個方案了。:) 不過，方案沒有絕對的好壞，關鍵還在於是否適合所在的場景。如果你有更好的方案，歡迎留言交流。
掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes
歡迎轉載，帶上以下二維碼即可
