如何处理在REST子集合的分页答案

【问题标题】：How to handle paging of child collections in REST如何处理在REST子集合的分页
【发布时间】：2014-08-03 17:13:34
【问题描述】：

我有一个实体，其中有多个子集合。在某些情况下，其中一些集合可以包含许多项目 (> 100)。然而，在大多数情况下，大约有 1-10 个，这很好。

当我显示我的主要实体时，如果有超过 10 条记录，我想通过分页显示这些子集合。

由于我不想将我的 JSON 响应包装在一个信封中，我正在使用我在收到时添加到响应中的 Content-Range 标头（例如 Content-Range：实体 11-20/400）收藏品一般。在这种情况下，我得到一个带有多个集合的实体。

（对“GET entities/123?AnotherChildrenCollection.PageSize=15&Children.PageSize=10&AnotherChidrenCollection.PageIndex=1”的示例实体响应

“实体”

{ 编号：123，孩子：[ { ChildID: 1 }, ... ] // 例如实际总数为 122 AnotherChildrenCollection: [ { ChildID: 1 }, ... ] // 例如实际总数为 130 }

到目前为止，唯一的想法是扩展 Content-Range 标头，所有子集合以逗号分隔并对其进行解析。

例如像这样：

内容范围：entities.Children 0-9/122，entities.AnotherChildrenCollection 15-29/130

是否有更好或更标准的方法来处理这个问题，因为这感觉有点像“黑客”

【问题讨论】：

【解决方案1】：

HTTP spec 不允许以这种方式使用内容范围。它只明确要求一个字节范围。考虑改用link headers。

例如，

Link: <"http://foo/bar">"; rel=next

添加多个链接头，其中每个rel= 值表示关系。在您的情况下，请使用“第一个”、“上一个”、“下一个”、“最后一个”。请注意，如果这样做，您将丢失记录总数。这就是人们使用信封的原因之一。

编辑：看来我对 HTTP 规范的阅读不准确。相关部分所说的是，客户不需要尊重任何其他范围类型。如果他们愿意，他们仍然可以。我还是会考虑使用链接头。

【讨论】：