我是一個REST noob嘗試設計我的第一個REST API模式。管理文件夾層次結構中資源的良好RESTful做法是什麼？
考慮一個簡單的REST API來列出/查看/編輯/刪除用戶對象。我們可以使用以下2種URL模式進行路由：
/users # GET returns a list of users, POST allows creation of new user
/users/{userid} # GET returns user info, PUT for updating user info, DELETE to delete user
到目前爲止，這麼好。現在讓我們說，用戶可以安排在可嵌套的文件夾中。所以用戶現在可以在一個文件夾內，並且一個文件夾可以包含用戶和子文件夾。要允許文件夾的管理，我們希望以下功能添加到我們的API：
- 目錄內容的文件夾
- 的（用戶和子文件夾）創建一個新的文件夾
- 重命名，刪除文件夾
- 用戶或子文件夾移動到不同的父文件夾
什麼是一個REST API提供此功能的最佳方式？我想出了兩個想法：
理念1：顯示文件夾層次URL
例如/users/folder1/folder2/chris
乍一看，這看起來不錯，但也有一些這種方法的問題：
用戶和文件夾現在具有相同的URL模式。無法知道
/users/a/b/c是否指向用戶或文件夾。這會導致難以理解的API，以及涉及手動解析URL和猜測的煩人實現。當客戶端發送
POST到/users/folder1我們不知道他們是要創建一個新用戶還是新建一個子文件夾。他們將不得不在請求主體中指定。再次，這導致惱人的服務器端實現，並且看起來不是很RESTful。沒有明顯的方式，允許從一個文件夾資源移動到另一個
理念2：添加父文件夾信息資源
保持如上所示的簡單的2 URL模式，將一個parentFolder字段添加到用戶資源。
例如一個GET到/users可以返回（在JSON）：
{'users':
[{'name':'chris','DoB':'1/1/1900','parentFolder':'/folder1/folder2'},
...]
}
添加單獨的URL模式/folders和/folders/{folderid}用於查看/編輯/刪除的文件夾。
這解決了與想法一的問題，但在設計方面，它讓我感到不安：
添加資源的父作爲資源的屬性似乎很奇怪。
爲什麼我們不得不將用戶和他們的文件夾分離到不同的API中，即使它們顯然是相互關聯的？
感謝您閱讀這篇文章。他們是否有更好的方式來處理這個問題？
這是什麼意思_to you_用戶在文件夾中？這個概念讓我感到困惑...... – 2011-05-27 14:45:44
@Donal：我承認把用戶放入文件夾並不那麼直觀。但是我們的產品允許用戶在文件夾層次結構中安排幾乎所有類型的對象，爲了保持一致性，我們還允許管理員將用戶分組到文件夾中。將來，API將支持系統中各種對象的管理，而不僅僅是用戶。 – 2011-05-30 00:19:14