小编Kar*_*tin的帖子

我有兴趣将直接REST接口暴露给JSON文档集合(想想CouchDB或Persevere).我遇到的问题是GET如果集合很大,如何处理集合根上的操作.

作为一个例子假装我暴露StackOverflow的Questions表,其中每一行都作为文档公开(不一定是这样的表,只是一个相当大的'文档'集合的具体例子).收集将在可提供/db/questions与通常的CRUD API GET /db/questions/XXX,PUT /db/questions/XXX,POST /db/questions是在玩.获取整个集合的标准方法是,GET /db/questions但如果天真地将每一行转储为JSON对象,那么您将获得相当大的下载和服务器上的大量工作.

解决方案当然是分页.Dojo 通过一个巧妙的RFC2616兼容扩展使用带有自定义范围单元的标头,在其JsonRestStore中解决了这个问题.结果是只返回请求的范围.这种方法优于查询参数的优点是它为查询留下了查询字符串(例如,或某些,以及是的,它被编码).Rangeitems206 Partial ContentGET /db/questions/?score>200%3E

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

该请求必须具有包含Range头部字段(部分14.35),指示在期望的范围,并且可以具有包括一个If-Range头字段(部分14.27),以使所述请求为条件.

这在标题使用标题的上下文中是有意义的,但是是一个问题因为我希望206响应是默认处理天真客户端/随机人员探索.

我已经仔细研究了RFC,寻找解决方案,但对我的解决方案一直不满意,并对SO对这个问题的看法感兴趣.

我有过的想法:

• 返回200了Content-Range头! - 我不认为这是错的,但我更喜欢一个更明显的指标,即响应只是部分内容.
• 返回400 Range Required - 所需标头没有特殊的400响应代码,因此必须手动使用和读取默认错误.这也使得通过Web浏览器(或像Resty这样的其他客户端)进行探索变得更加困难.
• 使用查询参数 - 标准方法,但我希望允许查询la Persevere,这会切入查询命名空间.
• 回来206吧! - 我认为大多数客户都不会惊慌失措,但我宁愿不反对RFC中的MUST
• 扩展规格!返回266 Partial Content - 行为与206完全相同,但是响应于不得包含Range …