假設我有一個由學校，學生和課程組成的三級層次結構。RESTFful /面向資源的設計
如果我將學生作爲一種資源，我的問題是我是否應該總是與該學生一起返回父母「學校」和孩子「班級」，或者是否應該包含用戶提供的parm以表明這種情況。或許像& deep = True？另一方面，如果一個用戶得到一個學生，並且他想要這所學校，他必須在學校資源上做一個GET，並且同樣如果他想要一個學生正在參加的所有課程，那麼他有在類資源上做一個GET？
我試圖讓未知的未知用戶保持開放的設計，而不是僅僅爲我們當前的需求需求編碼。
謝謝，
尼爾沃爾特斯
我認爲你應該避免將類視爲學生的子資源或屬性。學術課不僅僅是學生時間表上的一個時間段，它有一個教師，一個教學大綱等等，所有這些都可能需要在某個時刻編碼。
在我看來，以下關係成立：
（你也可以平凡地擴展這些教師/教師，如果你的要求nts包括這些信息。）
此外，上述每種資源類型將具有超出它們之間簡單鏈接的任何數量的屬性。
鑑於這種情況，我想你會希望有一個URL結構類似如下：
http://example.com/lms/schools =>學校名單http://example.com/lms/schools/{school} =>信息有關的一所學校http://example.com/lms/schools/{school}/students =>學生名單http://example.com/lms/schools/{school}/students/{student} =>一名學生的信息http://example.com/lms/schools/{school}/students/{student}/courses =>課程列表（如鏈接，未滿資源）學生就讀於http://example.com/lms/schools/{school}/courses =>課程列表http://example.com/lms/schools/{school}/courses/{course} =>信息上一個課程http://example.com/lms/schools/{school}/courses/{course}/students =>學生的名單（如鏈接，不充分的資源）報名參加課程謝謝，我喜歡你的例子。這是一個假設的例子，我試圖想到一個快速的3級層次結構。但是如果我知道學生證（例如社會安全號碼），我可能不知道他的學校ID。所以當我找回學生時，我可能也需要他的學校數據。 如果你的學校和學生都在URL上，這是否意味着兩者都會在結果數據結構中返回？ 也有興趣返回鏈接列表的想法。 – NealWalters 2009-09-30 18:32:04
我想，添加查詢參數來優化遞送是合理的。我可能會使它更通用並使用include=<relation>。這可以擴展到所有類型。請注意， 您可以使用多個包括：.../student/<id>?include=school&include=student將分配列表[school, student]到參數include。這也將允許對其他資源可能有用的一般模式。
這對我來說也是有意義的。 – NealWalters 2009-09-30 18:38:45
如果您考慮更多關於資源設計的思考UI設計的問題，那麼問題會變得更加容易。沒有理由不能在學生資源的表示中返回學校信息的子集，並且如果用戶希望看到更多信息，還可以返回指向學校資源的完整表示的鏈接。
我覺得REST接口更像是機器的用戶界面，而不是數據訪問層。有了這樣的思維模式，在不同資源表示中複製信息並不是問題。
我知道有很多人試圖像對待DAL一樣對待REST，但他們是同樣的人，當他們發現你不能通過RESTful界面進行交易時會感到不安。換句話說，設計你的API，就像設計一個網站（但沒有任何漂亮的東西）一樣，然後構建一個客戶端，它可以抓取該網站以獲取所需的信息。
謝謝。關於交易的好處！今天上午我花了幾個小時與我的同事討論了將所有東西「原子化」（即將單個數據庫表作爲單獨資源公開）與將「邏輯分組」組合成新的超級資源的優點/缺點。 – NealWalters 2009-10-02 18:03:13
其他這裏有提到的鏈接;這是REST的限制之一，即超文本作爲應用程序狀態的引擎。您的表示應包含指向相關資源的鏈接，例如，學生的代表應與他們所屬學校的資源有聯繫。請參閱http://stackoverflow.com/questions/717851/can-someone-explain-hypertext-as-engine-of-application-state-in-simple-terms瞭解更多信息。 – rojoca 2009-10-07 03:11:03