服務(wù)API的版本控制歷來(lái)沒(méi)有一個(gè)完美的解決方案，本篇列出了業(yè)界常見(jiàn)的三類(lèi)API版本控制方案，每一類(lèi)中又有1到2種實(shí)現(xiàn)方式（可能還有更多），看官們可根據(jù)自己項(xiàng)目的規(guī)模和要求選擇適合自己的方案。

1. 強(qiáng)制使用統(tǒng)一API版本

整個(gè)項(xiàng)目使用一個(gè)API版本,每次變更需要考慮向后兼容性，基本原則：只能在原來(lái)的結(jié)構(gòu)基礎(chǔ)上增加屬性，而不能刪除，同時(shí)需要客戶端進(jìn)行配合。

比如：有個(gè)返回值是string類(lèi)型，如果要變成int類(lèi)型，不能改變?cè)瓉?lái)的字段值，只能增加一個(gè)新的屬性，這樣才能保證老版本的正常使用。

缺點(diǎn)：返回?cái)?shù)據(jù)過(guò)于冗余，不好判斷哪個(gè)屬性是哪個(gè)版本在用，也就無(wú)法定期下線指定版本。

2. URI中顯式添加版本號(hào)

第一種，把版本號(hào)嵌入到URL路徑中，例如：http://example.com/v3/item/list

第二種，把版本號(hào)放在RequestParam中，例如：http://example.com/item/list?version=3

第一種方便在服務(wù)端用不同的方法進(jìn)行版本區(qū)分，第二種只能在同一個(gè)方法中進(jìn)行判斷區(qū)分。

有點(diǎn)：夠直觀，方便調(diào)試。

缺點(diǎn)：不符合RestFull原則（原則又不能當(dāng)飯吃，解決問(wèn)題才是王道），版本過(guò)多會(huì)不好控制。

3. 添加頭信息控制版本

第一種，?在Header中添加自定義參數(shù)，例如：? api-version: 2?

第二種，在ContentType中添加版本號(hào)，例如：Accept: application/vnd.haveibeenpwned.v2+json? 或 Accept: application/vnd.haveibeenpwned+json; version=2.0

優(yōu)點(diǎn)：符合RestFull原則，保持各版本的URL一致。

缺點(diǎn)：不夠直觀，只能使用帶有設(shè)置header的工具進(jìn)行調(diào)試。

縱觀各大網(wǎng)站的API，使用URL中顯示添加版本號(hào)的最多，添加頭部信息控制版本的次之，幾乎沒(méi)有強(qiáng)制使用統(tǒng)一版本的，so，you know~

關(guān)于版本過(guò)多難于維護(hù)的問(wèn)題，解決辦法是控制API使用周期，最多不超過(guò)5個(gè)版本同時(shí)在使用，并定期下架老舊的API版本。