做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/index.php/2013/11/25/understanding-the-costs-of-versioning
作者以數學的方式詳細的論述了這三種模式下，整個平台在升級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的效果。