談談API版本控制的策略

上篇寫《聊聊數據庫和緩存同步機制》的時候，收到一份讀者留言，但願我來談談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種版本控制模式，接下來，咱們來說講如何來落地執行每種模式：

無版本模式的可選執行方案

1. 新功能直接在老API上修改，強制調用方客戶端（iOS/Android/H5）升級，用戶體驗會受到影響，也有必定的技術難度，適用場景比較有限。

2. 更換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中「隱藏」起來。

1. 經過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

歡迎轉載，帶上如下二維碼便可