返回也是集合的资源表示的最佳实践
假设我想要创建一个RESTful接口，并且我希望根据foo的I来处理它们。这里没有什么新鲜事：
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从foo1中删除bar3。DELETE /api/foo1完全删除foo1。
现在的问题仍然是：GET /api/foo1是做什么的？它是否像我在这个问题中最初假设的那样返回foo1的表示？还是返回一个酒吧列表？还是返回foo1的表示形式，它既是对foo1的描述，也包括所有包含的条形条的列表？
或者GET /api/foo1应该像我在开始时假设的那样返回一个foo1的表示，并要求一个PROPFIND请求来列出foo1内部的条形图(WebDAV采用的方法)？但是，为了保持一致性，难道我不需要将我的所有其他列表类型的功能更改为PROPFIND，直接与成千上万的RESTful教程相矛盾，这些教程说要使用GET /api/foo1来列出内容？
回答 3
Stack Overflow用户
发布于 2016-11-15 14:27:18
经过一番思考，我认为从RESTful的角度来看，最好的概念解释是，“事物”通常与其“集合”不一样。因此，在WebDAV世界中，directory/可能与保存其文件的内容相同，而在RESTful世界中，我可能为包含的文件提供了一个单独的directory/files/子路径。这样，我就可以从保存的文件中分别操作目录。
考虑一个包含谷仓的农场的RESTful API。端点farm/api/barns/可能返回一个谷仓列表，其中一个将是farm/api/barns/bigredbarn。我天真地认为，检索farm/api/barns/bigredbarn/会给我一个谷仓里动物的列表，这就是引发这个问题的原因。
但实际上，谷仓里的动物只是大红谷仓的一个方面。它可能含有车辆和干草：
farm/api/barns/bigredbarn/animals/farm/api/barns/bigredbarn/vehicles/farm/api/barns/bigredbarn/haybales/
用这种方法，我所面临的困境就不会出现。
Stack Overflow用户
发布于 2016-11-06 21:23:51
webdav的语义从未真正与RESTful接口的习惯用法相一致。
理论上，GET应该检索资源状态的表示，PROPFIND应该用于检索集合的成员。
所以你应该这么做：
- 获取/api/ foo1 1/-只返回foo1的状态
- PROPFIND /api/ foo1 1/-返回foo1的成员
如果你告诉他们使用PROPFIND的话，大多数前端开发者都会抓狂，尽管浏览器js实现完全支持PROPFIND。
就我个人而言，我使用webdav/json网关，其中的请求是使用RESTful成语发出的，但是被路由到我的webdav实现中。
例如，我会这样做：
GET /api/foo1/_PROPFIND?fields=name,fooProp1,fooProp2那就会回来
[
{ name : "bar1", fooProp1: "..", fooProp2 : ".."},
{ name : "bar2", fooProp1: "..", fooProp2 : ".."}
]这种方法的一个优点是客户端可以控制返回的json属性。这是很好的，因为一个富API将有很多属性，但在大多数情况下，客户端并不需要所有这些属性。
Stack Overflow用户
发布于 2016-11-09 06:44:51
RESTfull API中的路由及其操作完全由开发人员设计。是开发人员在请求特定路由时决定返回什么，比如，GET /api/foo1。
开发人员应该设计包括/api/foo1/bar在内的每一条路线。对于某条路线应该做什么，并没有具体的规定。如果您的API是一个开放源码项目，那么对每一条路线都要做一个清晰清晰的文档。
不要把你的时间浪费在旧的学校策略上。
https://stackoverflow.com/questions/40451010
复制相似问题
腾讯云开发者
