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

问题描述

我有兴趣将直接REST接口暴露给JSON文档集合（想想 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的问题表，其中每一行都作为文档公开（不一定是这样的表，只是一个具体的例子）大量的文件集合。该集合将在 / 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通过一个聪明的RFC2616兼容扩展使用 JsonRestStore 解决了这个问题带有自定义范围单位 items 的范围标头。结果是 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 带内容范围标题！ - 我不认为这是错的，但我会更喜欢一个更明显的指标，即响应只是部分内容。


• 返回 400范围必需 - 所需的标头没有特殊的400响应代码，因此必须手动使用和读取默认错误。这也使得通过Web浏览器（或其他客户端，如Resty）进行探索变得更加困难。


• 使用查询参数 - 标准方法，但我希望允许查询la Persevere，这会切入查询命名空间。


• 只需返回 206 ！ - 我想大多数客户都不会惊慌失措，但我宁愿不反对RFC中的必要


• 扩展规范！返回 266部分内容 - 行为与206完全相同，但是响应的请求不得包含范围标题。我认为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屋！