做RESTful開放平臺，一方面其API變動越少，對API調用者越有利；另一方面，沒有人可以預測未來，系統在發展的過程中，不可避免的需要添加新的資源，或者修改現有資源。

因此，改動升級必不可少，但是，作為平臺開發者，你必須有覺悟：一旦你的API開放出去，有人開始用了，你就不能只管自己Happy了，你對平臺的任何改動都需要考慮對當前用戶的影響。

因此，做開放平臺，你從第一個API的設計就需要開始API的版本控制策略問題，API的版本控制策略就像是開放平臺和平臺用戶之間的長期協議，其設計的好壞將直接決定用戶是否使用該平臺，或者說用戶在使用之后是否會因為某次版本升級直接棄用該平臺。

API的版本控制策略通常有3種模式：

第一種：The Knot：無版本，即平臺的API永遠只有一個版本，所有的用戶都必須使用最新的API，任何API的修改都會影響到平臺所有的用戶。甚至平臺的整個生態系統。

第二種：Point-to-Point：點對點，即平臺的API版本自帶版本號，用戶根據自己的需求選擇使用對應的API，需要使用新的API特性，用戶必須自己升級。

第三種：Compatible Versioning：兼容性版本控制，和The Knot一樣，平臺只有一個版本，但是最新版本需要兼容以前版本的API行為。

三種策略對整個平臺在升級API的開銷對比如下：

以上信息來源于這篇文章： http://www.ebpml.org/blog2/in... 作者以數學的方式詳細的論述了這三種模式下，整個平臺在升級API上的開銷對比。

針對上面的論述，首先，API一定得有版本，否則升級對于用戶來說將是噩夢。其次，要做到Compatible Versioning有現實的限制，畢竟API升級時，不可避免的會出現無法兼容老版本的狀況，因此，版本控制需要結合第二種和第三種模式，即提供一個統一的兼容版本入口，同時對于不能兼容歷史版本的API保留歷史版本，支持用戶能夠調用到歷史版本的API。另外，對歷史版本的API支持一定要有時間和用戶限制，即老版API支持到一定時間就刪除，新用戶必須使用新版API，否則一個API有10個版本會讓平臺的維護非常痛苦。

URI vs Request Parameter vs Media Type
在RESTful API領域，關于如何做版本控制，目前業界比較主流的有3種做法：

第一種：URI， 即在URI中直接標記使用的是哪個版本，無版本號URI默認使用最新版本。如下：

http://xianlinbox/api/customers/1234 http://xianlinbox/api/v3.0/customers/1234

好處：
直接可以在URI中直觀的看到API版本，可以直接在瀏覽器的查看各個版本API的結果.

壞處：
版本號在URI中破壞了REST的HATEOAS（hypermedia as the engine of application state）規則。版本號和資源之間并無直接關系。

第二種：Request Parameter， 即在每個請求后添加一個version參數，表示請求的是哪個版本。如下：

http://server:port/api/customer/123?version=2

這種做法其實就是URI方式的變種，好壞處也都一樣。

第三種： Mdedia Type， 即在HTTP請求的header中使用Media Type標記該請求想獲取的資源， 同樣的可以不設置或設置通用的Media Type表示最新版本的API。

===> GET /customer/123 HTTP/1.1 Accept: application/vnd.xianlinbox.customer-v3+json<=== HTTP/1.1 200 OK Content-Type: application/vnd.xianlinbox.customer-v3+json{"customer":{"name":"Xianlinbox"} }

好處：
遵循了REST的設計風格.

壞處：
版本不直觀，需要能設置header的client才能調用查看該API的效果。

原文：http://itindex.net/detail/470...版本控制

總結

以上是生活随笔為你收集整理的RESTful API版本控制策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。