restful對應的中文是rest式的;或者叫rest風格的
rest式的web服務是一種roa(the resource-oriented architecture)(面向資源的架構).
在restful之前的操作：
http://127.0.0.1/user/query/1 get 根據使用者id查詢使用者資料
http://127.0.0.1/user/save post 新增使用者
http://127.0.0.1/user/update post 修改使用者資訊
http://127.0.0.1/user/delete get/post 删除使用者資訊
restful用法：
http://127.0.0.1/user/1 get 根據使用者id查詢使用者資料
http://127.0.0.1/user post 新增使用者
http://127.0.0.1/user put 修改使用者資訊
http://127.0.0.1/user delete 删除使用者資訊
一旦定義好了資源, 需要确定什麼樣的 actions 應用它們，這些 actions 怎麼映射到你的 api 上。restful 原則提供了 http methods 映射作為政策來處理 crud actions，如下：
get /tickets - 擷取 tickets 清單
get /tickets/12 - 擷取一個單獨的 ticket
post /tickets - 建立一個新的 ticket
put /tickets/12 - 更新 ticket #12
patch /tickets/12 - 部分更新 ticket #12
delete /tickets/12 - 删除 ticket #12
rest 非常棒的是，利用現有的 http 方法在單個的 /tickets 接入點上實作了顯著的功能。沒有什麼方法命名約定需要去遵循，url 結構是整潔幹淨的。 rest 太棒了!
接入點的名稱應該選擇單數還是複數呢？keep-it-simple原則可以在此應用。雖然你内在的文法知識會告訴你用複數形式描述單一資源執行個體是錯誤的，但實用主義的答案是保持url格式一緻并且始終使用複數形式。不用處理各種奇形怪狀的複數形式（比如person/people，goose/geese）可以讓api消費者的生活更加美好，也讓api提供者更容易實作api（因為大多數現代架構天然地将/tickets和/tickets/12放在同一個控制器下處理）。
但是你該如何處理（資源的）關系呢？如果關系依托于另外一個資源，restful原則提供了很好的指導原則。讓我們來看一個例子。supportfu的一個ticket包含許多消息（message）。這些消息邏輯上與/tickets接入點的映射關系如下：
get /tickets/12/messages - 擷取ticket #12下的消息清單
get /tickets/12/messages/5 - 擷取ticket #12下的編号為5的消息
post /tickets/12/messages - 為ticket #12建立一個新消息
put /tickets/12/messages/5 - 更新ticket #12下的編号為5的消息
patch /tickets/12/messages/5 - 部分更新ticket #12下的編号為5的消息
delete /tickets/12/messages/5 - 删除ticket #12下的編号為5的消息
------------------------- a little progress a day makes you a big success... ----------------------------