REST中依赖资源的设计模式

我正在为资源URI开发规范文档。在netz上，几乎所有内容都得到了很好的讨论，并且都非常有用。但是，我对依赖资源的模式有点执着。因此，依赖资源是以其父资源为乐而存在的东西。而且，如果父母不再存在，那么依赖者也会消失。所以，如果我有书，一个依赖的资源就是书的数量。对于任何给定的查询，如果没有书籍，则不进行计数。这不同于，比如说，一个作家。。。你可以没有书，但仍然有作者。好啊所以我有类似于这个URI的东西和返回的数据

http://example.com/books.json?author=Homer

{"books": [
    {"id": 33, "title": "Iliad", "author": "Homer", "pubyear": "800 BC"},
    {"id": 33, "title": "Odyssey", "author": "Homer", "pubyear": "750 BC"}
]}

URI以常用名词的复数形式结尾，查询字符串用于过滤返回集。返回“hash”中的根节点是被查询的普通名词，其键是一个数组，其中每个元素都是一个具有键/值对的hash

对于伯爵来说，我的本能是做以下事情

http://example.com/books/count.json?author=Homer

{"books": [
    {"count": 2}
]}

甚至

http://example.com/books/stats.json?author=Homer

{"books": [
    {"stats": {
        "count": 2,
        "units": 10,
        "sold": 3
    }
]}

但是，似乎正确的方法真的应该是

http://example.com/books.json/count?author=Homer or
http://example.com/books.json?aggregate=count&author=Homer

---

有什么建议和想法吗？

这两个看起来都很奇怪的原因是，你把“.json”放在了内容类型和内容标识符之间。内容类型应位于请求的“Accept”标头中。如果您删除“.json”，您考虑的两种可能性将减少到相同的东西

---

这是一个纯粹的答案。如果出于某种原因必须使用扩展（框架或客户端限制），则将扩展放在最后一个路径元素上更为标准。

谢谢。。。好建议。我想我会坚持使用扩展名作为标识符，因为它可以减少冗长的查询，并且更清楚地知道将返回什么。我理解将.json移动到“Accept”头的细节，但我不理解从URI中删除它如何以任何方式回答这个问题。请解释我在这里遗漏了什么——我想知道你是从哪里来的。