直接在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 v2_0_0()
}?>
客戶端在做請求的時候在介面中新增ver欄位,標識出請求的是哪個介面:
這種做起來比較簡單也容易理解,但是在你的每個介面邏輯裡面都得需要寫判斷版本的**了。比如
if ver == 'v1':
do_something_with_v1_style
elif ver == 'v2':
do_something_with_v2_style
這個可能需要再function中增加很多判斷來區分版本,這裡是否可以結合工廠模式來搞?
客戶端在做請求的時候在http head裡面中新增api-version欄位,標識出請求的是哪個介面:
這個需要統一做的事情稍微有點多,但之後的介面邏輯會比較好些。在入口的地方獲取介面版本,然後把請求分發到對應版本的介面處理器上。
api(req):
if req.heads["api-version"] == 'v1':
distribute_to_v1_api(req)
elif ver == 'v2':
distribute_to_v2_api(req)
不同版本使用不同的網域名稱,這樣:
網域名稱的方式可以採用下面的兩種方式:
1、不同版本的api部署成不同的應用(甚至可以部署到不同的伺服器上),彼此間獨立,其好處是部署的過程不會影響其他版本api的使用,並且可以減輕單台伺服器的負擔。
2、部署在乙個應用上面,但是和第四種一樣,在介面入口出分發到不同版本的介面處理器上進行處理。好處是不同版本間能夠直接復用相同的功能。
如果你的介面變化已經到了今天v1、明天v2、後天v3的地步,那麼得考慮你們一開始對產品的需求是否足夠準確了(估計需要維護的介面文件也會讓人頭疼);
不同版本介面相互獨立在某種程度上限制了你,讓你不會隨隨便便就v1、v2、v3。(當你每天都要用乙個新網域名稱的時候你自己一定會不自然的反思是不是變換太頻繁了);
介面版本資訊能夠直接在url裡面體現,清晰易懂,也比較容易做介面除錯;
不同的版本的api應用(或者介面處理器)之間彼此獨立,這符合軟體工程的低耦合原則。
如何優雅的定義 App 的介面設計
使用者體驗設計的概念非常廣泛,包含了使用者 挖掘使用者潛在動機和實用性 視覺沒感體驗等等,通俗來講,如何讓你乙個產品給使用者很爽的感覺,其中包含的知識和方法都是使用者體驗的一部分。1,擬定你的設計範圍 2,整理你的資訊架構 3,考慮資訊的不同狀態 4,考慮資訊的多樣性 5,考慮產品的視覺美感 下面還...
如何優雅的管理不同版本的API介面
api版本管理方式多種多樣 序號版本管理方式 簡要說明 1網域名稱區分管理 不同版本使用不同網域名稱,v1.api.amap.com,v2.api.amap.com 2請求url path區分管理 同一網域名稱,api.amap.com v1 api.amap.com v2 3請求引數區分管理 同一...
如何優雅地搞砸你的app
沒有商業意識 範圍蔓延 開發者變的盲目 置。另外一種避免開發者變盲目的方式被steve blank描述為 從開發中走出來 介紹了他們擺脫開發者盲目問題的方式。太少或沒有測試期 在正式發布之前,gmail作為內部專案在谷歌員工之間已經使用好幾年了。此後,它開始面向公眾發布,從一開始只有被邀請的人才能體...