[size=large][b]版本控制策略模式[/b][/size]
api的版本控制策略通常有3種模式：
第一種：the knot：無版本，即平台的api永遠只有乙個版本，所有的使用者都必須使用最新的api，任何api的修改都會影響到平台所有的使用者。甚至平台的整個生態系統。
[img]
第二種：point-to-point：點對點，即平台的api版本自帶版本號，使用者根據自己的需求選擇使用對應的api，需要使用新的api特性，使用者必須自己公升級。
[img]
第三種：compatible versioning：相容性版本控制，和the knot一樣，平台只有乙個版本，但是最新版本需要相容以前版本的api行為。
[img]
三種策略對整個平台在公升級api的開銷對比如下：
[img]
以上資訊**於這篇文章：[url]
作者以數學的方式詳細的論述了這三種模式下，整個平台在公升級api上的開銷對比。
針對上面的論述，首先，api一定得有版本，否則公升級對於使用者來說將是噩夢。其次，要做到compatible versioning有現實的限制，畢竟api公升級時，不可避免的會出現無法相容老版本的狀況，因此，版本控制需要結合第二種和第三種模式，即提供乙個統一的相容版本入口，同時對於不能相容歷史版本的api保留歷史版本，支援使用者能夠呼叫到歷史版本的api。另外，對歷史版本的api支援一定要有時間和使用者限制，即老版api支援到一定時間就刪除，新使用者必須使用新版api，否則乙個api有10個版本會讓平台的維護非常痛苦。
[size=large][b]uri vs request parameter vs media type [/b][/size]
在restful api領域，關於如何做版本控制，目前業界比較主流的有3種做法：
第一種：uri， 即在uri中直接標記使用的是哪個版本，無版本號uri預設使用最新版本。如下：
好處：
直接可以在uri中直觀的看到api版本，
可以直接在瀏覽器的檢視各個版本api的結果
壞處：第二種：request parameter， 即在每個請求後新增乙個version引數，表示請求的是哪個版本。如下：
這種做法其實就是uri方式的變種，好壞處也都一樣。
第三種： mdedia type， 即在http請求的header中使用media type標記該請求想獲取的資源， 同樣的可以不設定或設定通用的media type表示最新版本的api。
好處：遵循了rest的設計風格，
壞處：版本不直觀，需要能設定header的client才能呼叫檢視該api的效果。
版本控制 設計模式 模式版本控制
版本控制 設計模式 schema versioning changing a namespace is not versioning,it is new type creation.meta douglasp 架構版本控制 更改命名空間不是版本控制，而是建立新型別。meta douglasp ok....
SVN版本控制
1.svn安裝 sudo apt get install subversion 2.建立倉庫 對於多個 倉庫 首先在 var 下建立svn主目錄。svnadmin create var svn test1 svnadmin create var svn test2 3.修改配置檔案 倉庫目錄下 co...
走入《版本控制》
mkdir test cd test git init 建立空的本地倉庫 echo hello,world readme.txt 將標準輸出重定向到readme.txt git add 表示當前目錄下所有檔案git本地倉庫的暫存區 stage or index git commit m first ...