1、第一種形式：api版本號放在url路徑中
https://api.example.com/v1/user/ID https://api.example.com/v2/user/ID https://api.example.com/v3/user/ID
2、第二種形式：api版本號放在url參數中
https://api.example.com/user/ID?version=v1&.. https://api.example.com/user/ID?version=v2&.. https://api.example.com/user/ID?version=v3&..
這種做起來比較簡單也容易理解，但是在你的每個接口邏輯裏面都需要寫判斷版本的代碼。比如：
if(version=='v1'){ ... }else if(version=='v2'){ ... }
這樣的代碼看起來感覺很不舒服。而且會維護一大堆的if-else，以後會越來越長。
3、第三種形式：api版本號放在請求的header中
客戶端在做請求的時候，在HTTP HEAD裏面中添加API-VERSION字段，標識出請求的是哪個接口：
-H "API-VERSION: v1" -H "API-VERSION: v2"
這個需要統一做的事情稍微有點多，但之後的接口邏輯會比較好些。在入口的地方獲取接口版本，然後把請求分發到對應版本的接口處理器上。
4、第四種形式：api版本號放在二級域名中
不同版本使用不同的域名，例如：
v1.api.xxx.com
v2.api.xxx.com
域名的方式可以採用下面的兩種方式：
1、不同版本的api部署成不同的應用（甚至可以部署到不同的服務器上），彼此間獨立，其好處是部署的過程不會影響其他版本api的使用，並且可以減輕單臺服務器的負擔。
2、部署在一個應用上面，但是和第三種一樣，在接口入口處分發到不同版本的接口處理器上進行處理。好處是不同版本間能夠直接複用相同的功能。
總結一下：
個人比較傾向於第一種(xxx.com/v1/、xxx.com/v2/)：
在整個產品的生命週期中接口的數目和功能可能會不停的增加，但對於某個接口而言，不會頻繁的變動（修改接口的輸入輸出約定），而增加接口對於老的接口是沒有影響的，也就不會到必須升級接口的地步（你的老app只是在用原來就存在的老接口而已，新增加的接口對它沒有影響）。
如果你的接口變化已經到了今天v1、明天v2、後天v3的地步，那麼得考慮你們一開始對產品的需求是否足夠準確了（估計需要維護的接口文檔也會讓人頭疼）。
不同版本接口相互獨立在某種程度上限制了你，讓你不會隨隨便便就v1、v2、v3。（當你每天都要用一個新域名的時候你自己一定會不自然的反思是不是變換太頻繁了）。
接口版本信息能夠直接在url裏面體現，清晰易懂，也比較容易做接口調試（沒錯，給我一個Chrome就夠了）。
不同的版本的api應用（或者接口處理器）之間彼此獨立，這符合軟件工程的低耦合原則。
沒有很優雅的設計，只能自己考慮的長遠寫，接口的代碼寫的可擴展性高一些。App跟網站不一樣，即使你發新版了還是有很高几率用戶不買賬不更新的。所以最好在最初設計接口的時候就想的長遠些，API的URL不能隨便動，
所以設計核心業務的API只能考慮的比較清楚了，有些東西剛開始不做但是近期幾個版本要做的話就預先留好入口，代碼寫的可擴展性高一些方便以後兼容，數據庫中也可先預留好字段。
對版本接口維護,個人認爲是災難性的。不同版本的業務邏輯，需要操作最新版本的數據結構，同時還要維護各版本的文檔，各版本的自動化測試或者人工測試。
所以個人認爲比較好的做法是，在開始設計的時候，查詢類的接口,應儘可能使用被動式提供數據的無狀態接口，格式應竟可能使用對象(不使用二維的集合)，這樣的接口對於擴展字段非常的方便，也很容易做到向下兼容.
操作類的接口，儘可能地將資源分離，比如修改用戶信息，跟修改用戶頭像信息或者修改用戶職位信息，這樣的接口，儘可能使用獨立的資源。
對於實在沒有辦法需要全面升級接口的。
如果可能，保持原有的業務，原有的接口運轉正常。
然後構建一套全新的隔離的接口。
最後做下版本使用監控。當觀察到所有用戶都使用新版本的客戶端的時候，並保持一段時間的時候。放棄對老版本的維護，繼而下掉老版本的資源。當然，萬不得已的時候，還可以用強制更新。