寫一下我對restful的理解,最近換工作面試的時候有問到我restful api的東西,工作中以前很多專案也是webapi + js前臺控制元件的形式構建系統。實際上感覺restful太“理想化”,用起來不是特別順手, 舉例說明下:
先看看什麼叫restful:
REST的名稱"表現層狀態轉化"中,省略了主語。"表現層"其實指的是"資源"(Resources)的"表現層"。
所謂"資源",就是網路上的一個實體,或者說是網路上的一個具體資訊。它可以是一段文字、一張圖片、一首歌曲、一種服務,總之就是一個具體的實在。你可以用一個URI(統一資源定位符)指向它,每種資源對應一個特定的URI。要獲取這個資源,訪問它的URI就可以,因此URI就成了每一個資源的地址或獨一無二的識別符。
客戶端用到的手段,只能是HTTP協議。具體來說,就是HTTP協議裡面,四個表示操作方式的動詞:GET、POST、PUT、DELETE。它們分別對應四種基本操作:GET用來獲取資源,POST用來新建資源(也可以用於更新資源),PUT用來更新資源,DELETE用來刪除資源。
GET /tickets # 獲取ticket列表
GET /tickets/12 # 檢視某個具體的ticket
POST /tickets # 新建一個ticket
PUT /tickets/12 # 更新ticket 12.
實際上呢,不是所有的東西都是“資源”,尤其是在業務系統中,缺點如下:
有個介面是更新訂單狀態,你是用上面的GET POST PUT DELETE 哪個呢,看樣子應該是PUT,但是路徑呢PUT /tickets/12
我有時候多個介面 ,更新訂單收款狀態,更新訂單支款狀態,更新訂單結算狀態;
Restful 的路徑明顯不友好不夠用;
比如,Resuful要求 GET /tickets # 獲取ticket列表 。我們曾經有個需求,對方會把不超過1000個訂單id傳給我們,我們系統過濾其中一部分特殊訂單;這也是個查詢服務,用GET /tickets # 獲取ticket列表的形式,1000個訂單id顯然是超過GET url長度的,這裡也不合適;再者,我想開發多個條件查詢列表服務,路徑這麼淺顯然不合適;
實際業務中,我們webapi的路徑是這樣的:systemAlias/controller/action
總結下規則:
簡單查詢儘量用GET,好處是可以直接帶查詢引數copy api路徑;
複雜查詢和更新用POST,用的最多;
不用PUT和DELETE,原因是增加複雜度,並沒有帶來什麼好處
看看BAT的很多openapi,也是寫著restful,實際沒有嚴格遵守,都是get和post,這是也很多人不知道put和delete的原因
寫一下我對restful的理解,最近換工作面試的時候有問到我restful api的東西,工作中以前很多專案也是webapi + js前臺控制元件的形式構建系統。實際上感覺restful太“理想化”,用起來不是特別順手, 舉例說明下:
先看看什麼叫restful:
REST的名稱"表現層狀態轉化"中,省略了主語。"表現層"其實指的是"資源"(Resources)的"表現層"。
所謂"資源",就是網路上的一個實體,或者說是網路上的一個具體資訊。它可以是一段文字、一張圖片、一首歌曲、一種服務,總之就是一個具體的實在。你可以用一個URI(統一資源定位符)指向它,每種資源對應一個特定的URI。要獲取這個資源,訪問它的URI就可以,因此URI就成了每一個資源的地址或獨一無二的識別符。
客戶端用到的手段,只能是HTTP協議。具體來說,就是HTTP協議裡面,四個表示操作方式的動詞:GET、POST、PUT、DELETE。它們分別對應四種基本操作:GET用來獲取資源,POST用來新建資源(也可以用於更新資源),PUT用來更新資源,DELETE用來刪除資源。
GET /tickets # 獲取ticket列表
GET /tickets/12 # 檢視某個具體的ticket
POST /tickets # 新建一個ticket
PUT /tickets/12 # 更新ticket 12.
實際上呢,不是所有的東西都是“資源”,尤其是在業務系統中,缺點如下:
有個介面是更新訂單狀態,你是用上面的GET POST PUT DELETE 哪個呢,看樣子應該是PUT,但是路徑呢PUT /tickets/12
我有時候多個介面 ,更新訂單收款狀態,更新訂單支款狀態,更新訂單結算狀態;
Restful 的路徑明顯不友好不夠用;
比如,Resuful要求 GET /tickets # 獲取ticket列表 。我們曾經有個需求,對方會把不超過1000個訂單id傳給我們,我們系統過濾其中一部分特殊訂單;這也是個查詢服務,用GET /tickets # 獲取ticket列表的形式,1000個訂單id顯然是超過GET url長度的,這裡也不合適;再者,我想開發多個條件查詢列表服務,路徑這麼淺顯然不合適;
實際業務中,我們webapi的路徑是這樣的:systemAlias/controller/action
總結下規則:
簡單查詢儘量用GET,好處是可以直接帶查詢引數copy api路徑;
複雜查詢和更新用POST,用的最多;
不用PUT和DELETE,原因是增加複雜度,並沒有帶來什麼好處
看看BAT的很多openapi,也是寫著restful,實際沒有嚴格遵守,都是get和post,這是也很多人不知道put和delete的原因