第一種形式：
直接在controllers文件夾下增加對應版本號的文件夾，然后將controller文件放到對應的文件夾下。
訪問形式:http://***.***.com/V1/mobile/***
Controller/V1/
-----------------/MobileController.php
-----------------/ShowController.php
Controller/V2/
-----------------/MobileController.php
-----------------/ShowController.php
第二種形式：
Controller/
----------/MobileGetDetailController.PHP
----------/ShowController.php
----------/UploadImageController.php
MobileGetDetailController.php 內容如下
<?php class MobileGetDetail extends ApiController{ public function v1_0_0(){ } public function v2_0_0(){ } } ?>第三種形式
客戶端在做請求的時候在接口中添加ver字段，標識出請求的是哪個接口：
- api.xxx.com/api?ver=v1&...
- api.xxx.com/api?ver=v2&...
這種做起來比較簡單也容易理解，但是在你的每個接口邏輯里面都得需要寫判斷版本的代碼了。比如
if ver == 'v1': do_something_with_v1_style elif ver == 'v2': do_something_with_v2_style 這個可能需要再function中增加很多判斷來區分版本，這里是否可以結合工廠模式來搞？
第四種形式
客戶端在做請求的時候在HTTP HEAD里面中添加API-VERSION字段，標識出請求的是哪個接口：
- -H "API-VERSION: v1"
- -H "API-VERSION: v2"
這個需要統一做的事情稍微有點多，但之后的接口邏輯會比較好些。在入口的地方獲取接口版本，然后把請求分發到對應版本的接口處理器上。
api(req):
if req.HEADS["API-VERSION"] == 'v1': distribute_to_v1_api(req) elif ver == 'v2': distribute_to_v2_api(req) 第五種
不同版本使用不同的域名，這樣：
- v1.api.xxx.com
- v2.api.xxx.com
域名的方式可以采用下面的兩種方式：
1、不同版本的api部署成不同的應用（甚至可以部署到不同的服務器上），彼此間獨立，其好處是部署的過程不會影響其他版本api的使用，並且可以減輕單台服務器的負擔。
2、部署在一個應用上面，但是和第四種一樣，在接口入口出分發到不同版本的接口處理器上進行處理。好處是不同版本間能夠直接復用相同的功能。
總結：
- 在整個產品的生命周期中接口的數目和功能可能會不停的增加，但對於某個接口而言，不會頻繁的變動（修改接口的輸入輸出約定），而增加接口對於老的接口是沒有影響的，也就不會到必須升級接口的地步（你的老app只是在用原來就存在的老接口而已，新增加的接口對它沒有影響）；
- 如果你的接口變化已經到了今天v1、明天v2、后天v3的地步，那么得考慮你們一開始對產品的需求是否足夠准確了（估計需要維護的接口文檔也會讓人頭疼）；
- 不同版本接口相互獨立在某種程度上限制了你，讓你不會隨隨便便就v1、v2、v3。（當你每天都要用一個新域名的時候你自己一定會不自然的反思是不是變換太頻繁了）；
- 接口版本信息能夠直接在url里面體現，清晰易懂，也比較容易做接口調試；
- 不同的版本的api應用（或者接口處理器）之間彼此獨立，這符合軟件工程的低耦合原則。