求解惑如何設計RESTFUL服務

1樓：

從現在已有的框架來看，對資源的操作一般都是對映到物件方法上的。對資源的設計是粗粒度的，而不是從底層資料庫出發來設計資源。用成熟的框架來完成RESTful設計，一般還是資源-物件-關聯式資料庫，之間包含了兩層對映。

2樓：肥肥

樓上說的在理,RESTFUL 系統設計應該從業務出發，而不應該從底層資料庫出發。

先構思你系統當中業務範疇與功能，然後在將資料庫CRUD歸入業務操作，考慮資料庫如何去配合業務流程。

3樓：楊益

樓主應該對REST有基本了解，所以基本概念我就不再重複，只說一下樓主比較糊塗的點

資源並不是對底層儲存物件或者程式Model的直接對映

並不是說你有User表和Role表，就一定要設計對應的資源。

實際上RESTful資源和底層儲存服務之間的關係類似於關係式資料庫內的表和檢視的關係，檢視是根據實際查詢需要組合多個表形成的關係集合。

無論你的儲存服務到底是關係式資料庫還是NoSQL資料庫甚至文字檔案，對於訪問資源的客戶端來說都是一樣的。

所以建立乙個使用者，同時設定其角色，完全可以用POST /user直接完成

// 建立具有foo和bar兩個角色的新使用者

POST /user

// 如果response header能夠包含以下兩條最好

// 以201狀態響應，用Location告知新資源url

HTTP/1.1 201 Created

Location: /user/1

// 修改使用者的角色為foobar

PUT /user/1

// 修改使用者的密碼

PUT /user/1

至於/UserRoleRelation這樣粒度比較小的資源，我建議先不要，資源的粒度應該是先粗後細，根據業務後續的演化和實際需要再考慮是否抽象更細粒度的資源，一開始就搞得太細的話，任何一次操作都會被分解為多次網路IO，且系統複雜度容易搞得比較高。

把具體的資料庫表對映為資源，然後把CRUD動作對應到GET/POST/PUT/DELETE上，既傻又不安全，本來這些東西都是為業務服務，因為業務需求而存在的，結果抽象時卻不圍繞業務設計，這是本末倒置。

正確的思路應該是，忘記什麼資料庫和程式Model，只從HTTP的角度考慮，根據業務，需要設計哪些資源(url)，GET/POST時接受和響應哪些引數，把這些敲定之後，再從資料庫和程式Model上去考慮如何配合。