休息集合中的分页 [英] Paging in a Rest Collection

问题描述

我有兴趣向 JSON 文档集合公开直接 REST 接口(想想 CouchDB 或 坚持).我遇到的问题是如果集合很大，如何处理集合根目录上的 GET 操作.

I'm interested in exposing a direct REST interface to collections of JSON documents (think CouchDB or Persevere). The problem I'm running into is how to handle the GET operation on the collection root if the collection is large.

作为一个例子，假设我正在公开 StackOverflow 的 Questions 表，其中每一行都作为文档公开(不一定有这样的表，只是一个相当大的文档"集合的具体示例').该集合将在 /db/questions 上提供，使用通常的 CRUD api GET/db/questions/XXX, PUT/db/questions/XXX，POST/db/questions 正在发挥作用.获取整个集合的标准方法是 GET/db/questions 但如果这天真地将每一行转储为 JSON 对象，您将获得相当大的下载量和大量工作服务器.

As an example pretend I'm exposing StackOverflow's Questions table where each row is exposed as a document (not that there necessarily is such a table, just a concrete example of a sizable collection of 'documents'). The collection would be made available at /db/questions with the usual CRUD api GET /db/questions/XXX, PUT /db/questions/XXX, POST /db/questions is in play. The standard way to get the entire collection is to GET /db/questions but if that naively dumps each row as a JSON object, you'll get a rather sizeable download and a lot of work on the part of the server.

解决方案当然是分页.Dojo 在其 JsonRestStore 中通过巧妙的符合 RFC2616 的扩展解决了这个问题使用带有自定义范围单位 items 的 Range 标头.结果是一个206 Partial Content，它只返回请求的范围.这种方法相对于查询参数的优势在于，它将查询字符串留给...查询(例如 GET/db/questions/?score>200 或类似的，是的，它会被编码%3E).

The solution is, of course, paging. Dojo has solved this problem in its JsonRestStore via a clever RFC2616-compliant extension of using the Range header with a custom range unit items. The result is a 206 Partial Content that returns only the requested range. The advantage of this approach over a query parameter is that it leaves the query string for...queries (e.g. GET /db/questions/?score>200 or somesuch, and yes that'd be encoded %3E).

这种方法完全涵盖了我想要的行为.问题是 RFC 2616 在 206 响应中指定(强调我的):

This approach completely covers the behavior I want. The problem is that RFC 2616 specifies that on a 206 response (emphasis mine):

请求必须包含 Range 标头字段(第 14.35 节)指示所需的范围，并且可能包含一个 If-Range标头字段(第 14.27 节)使请求有条件.

The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.

这在标头的标准用法的上下文中是有道理的，但这是一个问题，因为我希望 206 响应成为处理天真的客户/随机探索的人的默认值.

This makes sense in the context of the standard usage of the header but is a problem because I'd like the 206 response to be the default to handle naive clients/random people exploring.

我已经详细阅读了 RFC 以寻找解决方案，但对我的解决方案不满意，并且对 SO 对这个问题的看法很感兴趣.

I've gone over the RFC in detail looking for a solution but have been unhappy with my solutions and am interested in SO's take on the problem.

我的想法:

• 返回 200 并带有 Content-Range 标头！ - 我不认为这是错误的，但如果一个更明显的指标，表明响应只是部分内容.
• Return 400 Range Required - 没有特殊的 400 响应代码需要的头部，所以必须使用默认错误并手动读取.这也使得通过网络浏览器(或其他一些客户端，如 Resty)进行探索变得更加困难.
• 使用查询参数 - 标准方法，但我希望允许查询坚持不懈，这会切入查询命名空间.
• 只需返回 206！ - 我认为大多数客户不会惊慌失措，但我宁愿不违反 RFC 中的 MUST
• 扩展规范！返回 266 部分内容 - 行为与 206 完全相同，但响应的请求不得包含 Range 标头.我认为 266 足够高，我不应该遇到碰撞问题，这对我来说很有意义，但我不清楚这是否被视为禁忌.

• Return 200 with a Content-Range header! - I don't think that this is wrong, but I'd prefer if a more obvious indicator that the response is only Partial Content.
• Return 400 Range Required - There is not a special 400 response code for required headers, so the default error has to be used and read by hand. This also makes exploration via web browser (or some other client like Resty) more difficult.
• Use a query parameter - The standard approach, but I'm hoping to allow queries a la Persevere and this cuts into the query namespace.
• Just return 206! - I think most clients wouldn't freak out, but I'd rather not go against a MUST in the RFC
• Extend the spec! Return 266 Partial Content - Behaves exactly like 206 but is in response to a request that MUST NOT contain the Range header. I figure that 266 is high enough that I shouldn't run into collision issues and it makes sense to me but I'm not clear on whether this is considered taboo or not.

我认为这是一个相当普遍的问题，并且我希望看到它以一种事实上的方式完成，这样我或其他人就不会重新发明轮子.

I'd think this is a fairly common problem and I'd like to see this done in a sort of de facto fashion so I or someone else isn't reinventing the wheel.

当集合很大时，通过 HTTP 公开完整集合的最佳方式是什么?

What's the best way to expose a full collection via HTTP when the collection is large?

推荐答案

我的直觉是 HTTP 范围扩展不是为您的用例设计的，因此您不应该尝试.部分响应意味着 206，并且 206 必须仅在客户端请求时才发送.

My gut feeling is that the HTTP range extensions aren't designed for your use case, and thus you shouldn't try. A partial response implies 206, and 206 must only be sent if the client asked for it.

您可能需要考虑一种不同的方法，例如在 Atom 中的使用(其中设计表示可能是部分的，并返回状态 200 和可能的分页链接).请参阅 RFC 4287 和 RFC 5005.

You may want to consider a different approach, such as the one use in Atom (where the representation by design may be partial, and is returned with a status 200, and potentially paging links). See RFC 4287 and RFC 5005.

这篇关于休息集合中的分页的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！