restful優缺點？

寫一下我對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.

DELETE /tickets/12 #刪除ticekt 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的原因