寫一下我對restful的理解，最近換工作面試的時候有問到我restful api的東西，工作中以前很多專案也是webapi + js前台控制項的形式構建系統。實際上感覺restful太「理想化」,用起來不是特別順手, 舉例說明下：
先看看什麼叫restful：
rest的名稱"表現層狀態轉化"中，省略了主語。"表現層"其實指的是"資源"（resources）的"表現層"。
所謂"資源"，就是網路上的乙個實體，或者說是網路上的乙個具體資訊。它可以是一段文字、一張、一首歌曲、一種服務，總之就是乙個具體的實在。你可以用乙個uri（統一資源定位符）指向它，每種資源對應乙個特定的uri。要獲取這個資源，訪問它的uri就可以，因此uri就成了每乙個資源的位址或獨一無二的識別符。
客戶端用到的手段，只能是http協議。具體來說，就是http協議裡面，四個表示操作方式的動詞：get、post、put、delete。它們分別對應四種基本操作：get用來獲取資源，post用來新建資源（也可以用於更新資源），put用來更新資源，delete用來刪除資源。
實際上呢，不是所有的東西都是「資源」，尤其是在業務系統中，缺點如下：
有個介面是更新訂單狀態，你是用上面的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¶m2=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理解不夠，覺得這種變種的服務路徑才是最優解，有大俠歡迎教育 :)
Restful的學習理解
最近工作需要用到restful，以前沒有關注過。都是寫一些linux驅動，qemu模擬器開發等。把心得寫一下。restful 這是乙個面向資源的架構，由一名老外提出的。屬於一種約束。只要遵從這種約束的都可以稱為resetful。但是不能叫restful架構，因為它根本就不是什麼架構。進入正題 什麼是...
對restful的理解
理解restful之前先來了解一下rest.rest 英文 representational state transfer，簡稱 rest，意思是 資源 表述性狀態轉化 描述了乙個架構樣式的網路系統，比如 web 應用程式。它是一種軟體架構風格 設計風格，而不是標準，只是提供了一組設計原則和約束條件...
理解RESTful架構
理解restful架構 restful的精闢理解 看url就知道要什麼 看http method就知道幹什麼 看http status code就知道結果如何 rest不是 rest 這個單詞，而是幾個單詞縮寫。但即使那幾個單詞說出來，也無法理解在說什麼 不是要貶低人，是我自己也理解困難 rest描...