假设我想制作一个 RESTful 界面，并且我想使用 foo s 基于他们的 ID。这里没有什么新东西:
GET /api/foo1返回 foo1 的表示(例如使用 JSON) . DELETE /api/foo1删除 foo1 . 等等。
现在让我告诉你“foo”是一个集合类型的东西。所以我希望能够在“foo”中添加一个“bar”:
PUT /api/foo1/bar3添加 bar3至 foo1 . GET /api/foo1/bar3返回 foo1 的表示. DELETE /api/foo1/bar3删除 bar3来自 foo1 . DELETE /api/foo1删除 foo1共。 现在问题仍然存在:什么是
GET /api/foo1做？它是否只是返回 foo1 的表示？正如我在这个问题中最初假设的那样？或者它返回一个酒吧列表？或者它是否返回 foo1 的表示这既是对 foo1 的描述以及包括所有包含的酒吧的列表？还是应该
GET /api/foo1仅返回 foo1 的表示正如我一开始假设的那样，需要一个 PROPFIND请求列出里面的酒吧 foo1 (WebDAV 采取的方法)？但是为了保持一致，我是否不必将所有其他列表类型功能更改为 PROPFIND ，直接与所有那些说要使用 GET /api/foo1 的 RESTful 教程相矛盾。列出内容？
最佳答案
经过一番思考，我认为从 RESTful 的角度最好的概念解释是，通常“事物”与其“集合”不同。因此，在 WebDAV 世界中，directory/可能与保存其文件的东西相同，在 RESTful 世界中，我可能有一个单独的 directory/files/包含文件的子路径。这样我就可以将目录与保存的文件分开操作。
考虑一个包含谷仓的农场的 RESTful API。端点 farm/api/barns/可能会返回一个谷仓列表，其中之一是 farm/api/barns/bigredbarn .我天真地认为检索 farm/api/barns/bigredbarn/会给我提供谷仓里的动物 list ，这就是提出这个问题的原因。
但实际上，谷仓里的动物只是大红谷仓的一方面。它可能包含车辆和干草:
farm/api/barns/bigredbarn/animals/ farm/api/barns/bigredbarn/vehicles/ farm/api/barns/bigredbarn/haybales/ 通过这种方法，我面临的困境不会出现。
关于rest - 返回也是集合的资源表示的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40451010/