为什么大多数API分页不依赖于HTTP Range头？

Question

我搜索了很多，但是找不到一个好的答案来回答这个问题。作为一个HATEOAS爱好者，我认为这个头部信息非常适合：

    Range: item=1-20/100

在HTTP规范中，我不太理解一些"矛盾之处": 范围单元可以接受"其他范围单元"...

范围单元可以接受“other-range-unit”这个参数，看起来支持自定义的范围单元，但是实际上只有在服务器端能正确处理自定义范围请求时才行。如果客户端使用了一个未被服务器支持的范围单元，服务器应该返回416状态码。

  range-unit       = bytes-unit | other-range-unit
  bytes-unit       = "bytes"
  other-range-unit = token

然而规范后来明确说明：

HTTP/1.1 定义的唯一范围单位是“字节”。使用其他单位指定的范围，HTTP/1.1 实现可能会忽略掉。

最后规范以此声明结束：

HTTP/1.1 已经被设计成允许应用实现不依赖于范围知识的实现。

• 除了字节单位，还允许使用其他单位吗？
• 如果 HTTP/1.1 被设计成允许应用不依赖于范围知识，那么依赖范围知识有什么真正的缺点？

注：我不关心“可浏览性”。

- ludofleury

---

你在标题中提出的问题已经通过规范中的信息得到了回答：因为“字节”在大多数情况下不是一个可用的分页测量单位。而且，由于其他范围单位可能会被忽略，以及范围本身可能会被忽略，所以它对于任何应该使用符合规范的 任何 HTTP 实现访问的 API 都是不可用的。 - CBroe

Answer 1

以下是我从这个问题中借鉴的答案，感谢@ptidel提供： Content-Range header - allowed units?

首先，在这个草案HTTP/1.1, part 5: Range Requests and Partial Responses中提出了自定义单位。

其次，两者之间有微妙的差别，第一个陈述是为了解析目的而做出的。

    range-unit       = bytes-unit | other-range-unit
    bytes-unit       = "bytes"
    other-range-unit = token

第二个语句是用于生成HTTP请求的。

最后，Ferenc Mihaly的整个评论完美地总结了这种情况：

当我发送[自定义范围单元]时，我遵循HTTP规范，而当他们忽略它时，他们也遵循HTTP规范

WebDAV正确使用HTTP扩展，但由于这个原因，在互联网上很少起作用

- ludofleury

Answer 2

大多数情况下，您不希望默认显示所有项目。对于使用?p=2样式的页面，保留根/用于第一页是可以的。使用“范围”标头会产生奇怪的行为。HTTP很久以前就变得过于臃肿了，因此我不建议将其所有标头都视为真实。

- Ivan Kleshnin