Restful的理解，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的緣由

 

如：

//根據訂單id獲取訂單

GET oms/order/queryOrderById?id=value1&param2=value2

 

//根據訂單id List獲取訂單

POST oms/order/queryOrderByIdList

 

//根據條件查詢訂單，帶分頁參數

POST oms/order/queryOrderByCondition

 

//更新訂單收款狀態

POST oms/order/updateOrderCollectionStatus

 

//批量更新訂單收款狀態

POST oms/order/updateOrderCollectionStatusInBatch

 

//批量更新訂單收款狀態

POST oms/order/updateOrderCollectionStatusInBatch

 

//批量刪除訂單，帶操做來源

POST oms/order/deleteOrderInBatch

 

多是我對Restful理解不夠，以爲這種變種的服務路徑纔是最優解，有大俠歡迎教育 :)