寫一下我對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的原因