我有一個用戶創建人員記錄的表單。每個人可以有幾個屬性 - 身高，體重等，但他們也可以有相關數據列表，如興趣愛好，最喜歡的電影等。在單個POST中創建複雜對象是RESTful嗎？
我有一個表單，收集所有這些數據。對我來說，似乎我應該在一個請求中發佈所有這些數據。但那是RESTful嗎？我的閱讀表明，興趣，最喜歡的電影和其他列表應該添加在單獨的POST請求中。但我不認爲這是有道理的，因爲其中一個可能會失敗，然後會有一部分人插入，可能會失去他們的興趣或最喜歡的電影。
我認爲在一個請求中添加所有數據並不存在問題，只要它與主資源（即您的案例中的人）固有相關。如果感興趣，最喜歡。電影等是他們自己的資源，他們也應該如此處理。
如何確定某物是否屬於自己的資源？我的意思是技術上個人的利益就是事物，但他們依賴於一個人的存在。 – 2011-06-07 13:08:04
在這種情況下，我會將Person作爲資源。如果一部電影是你想要單獨演繹的東西（例如通過某個ID）並且只是從一個人引用它（例如從列表中選擇），我認爲電影應該有自己的創建，刪除等手段，因此是視爲獨立資源。既然它只能存在於一個Person的上下文中，我認爲它也可以在一個請求中處理。 – Dirk 2011-06-07 13:09:31
「如何確定某物是否屬於自己的資源？」 - >它擁有自己的URI。 – DanMan 2013-02-19 17:09:15
我想說它完全取決於依賴數據的可尋址性和唯一性。
如果您的用戶相關數據依賴於用戶（例如，「獨特」字符串，例如表示電影（未經驗證）名稱的字符串等屬性），那麼它應該包含在POST創建用戶表示;然而，如果數據獨立於用戶（其中數據可以獨立於用戶尋址，例如參考，諸如來自一組電影的電影），則應該獨立地添加數據。
背後的推理是，與原始POST捆綁在一起時的參考添加意味着事務性;也就是說，如果另一個用戶在客戶端上選擇了「喜歡」電影的時候刪除了「喜歡」電影的電影引用，並且當POST通過時，用戶添加將會（應該通過該設計）失敗，而如果「最喜歡」電影不是關聯的，而只是一個屬性，沒有什麼可以失敗（屬性（大概）不能被第三方無效）。
再一次，這非常符合您的具體需求，但我側重於允許部分插入和指示失敗。處理這種事情的正確方法是，如果你真的不想允許部分插入，只是在後端實現事務;他們是真正處理在關鍵相關資源在流程中移除的情況的唯一途徑。
REST中的真正限制是，對於您獲取的可修改資源，您還可以轉身並將相同的表示重新放回以更改其狀態。或POST。因爲獲得大量其他資源的資源是合理的（也是非常普遍的），所以也可以把大量的東西放在一起。
非常廣泛地考慮REST中的資源。他們可以與數據庫行一對一映射，但他們不需要。可尋址資源可以嵌入其他可尋址資源，或者包含指向它們的鏈接。只要您尊重您的表示和底層協議操作的語義（即HTTP GET POST PUT等），REST就沒有任何關於可能會讓您的生活更輕鬆或更難的其他設計考慮因素的說法。
如果信息從用戶的角度來看屬於單一形式，那麼_surely_您應該將其作爲一個POST使用？如果你願意，你可以在幕後做些聰明的事情，但是不要讓客戶端的交互更加複雜。 – 2011-06-07 23:59:29
@Donal：我非常不同意; RESTful設計的重要一點是客戶端應該管理應用程序狀態。對於任何不平凡的問題，這涉及到客戶跟蹤多個國家。對於「單一形式/單一POST」範例，您通過限制狀態粒度來削弱客戶管理狀態的能力。 – 2011-06-08 16:04:08