Question

我正在为资源URI开发specs doc。 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以普通名词的复数形式结束，QUERY_STRING用于过滤返回集。返回“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”来混合内容类型和内容标识符。内容类型应位于请求的“Accept”标头中。如果你消除了“.json”，那么你正在考虑的两种可能性会降低到同样的程度。

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

REST中依赖资源的设计模式

1 个答案: