rest - REST 中依赖资源的设计模式

Question

我正在为资源 URI 开发规范文档。大多数事情都在 netz 上得到了很好的讨论，并且都非常有帮助。但是，我有点坚持依赖资源的模式。因此，依赖资源 是根据其父资源的喜好而存在的。而且，如果 parent 不复存在，那么受抚养人也会消失。所以，如果我有书，依赖资源就是书的数量。对于任何给定的查询，如果没有书籍，则不会有计数。这与作者不同……你可以没有书，但仍然有作者。行。所以我有类似这个 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 以普通名词的复数形式结尾，QUERY_STRING 用于过滤返回集。返回“hash”中的根节点是被查询的普通名词，它的key是一个数组，每个元素都是一个键/值对的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

有什么建议、想法吗？

Answer 1

两者看起来都很奇怪的原因是您通过在其上放置“.json”来混合内容类型和内容标识符。内容类型应位于请求的“接受” header 中。如果您删除“.json”，您正在考虑的两种可能性将减少为同一件事。

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