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

【问题标题】：Why most API paginations do not rely on HTTP Range header?为什么大多数 API 分页不依赖 HTTP Range 标头？
【发布时间】：2023-03-03 03:51:01
【问题描述】：

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

    Range: item=1-20/100

在 HTTP 规范中，我不理解一些“矛盾”：范围单位可以接受“其他范围单位”...

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

...但规范稍后是明确的：

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

最后，规范以这样的声明结束：

HTTP/1.1 旨在允许实施不依赖于范围知识的应用程序。

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

【问题讨论】：

您在标题中提出的问题通过规范中的信息自行回答：因为在大多数情况下，“字节”不是用于分页的可用度量单位。并且由于其他范围单位可能会被忽略，以及通常的范围，它只是不适用于任何应该可以通过符合规范的 any HTTP 实现访问的 API。跨度>

【解决方案1】：

感谢@ptidel，这是我从这个问题中轻轻借来的答案：Content-Range header - allowed units?。

其次，有一个细微的差别，第一个语句是为了解析目的而做的

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

虽然第二条语句用于产生 HTTP 请求。

最后，Ferenc Mihaly 的整条评论完美地总结了当时的情况：

我在发送 [自定义范围单位] 时符合 HTTP 规范，而当他们忽略它时它们符合 HTTP

WebDAV 正确使用 HTTP 扩展，IMO，但正是因为这个原因，它很少在 Internet 上运行

【讨论】：

【解决方案2】：

大多数情况下，您不想默认显示所有项目。对于 ?p=2 样式页面，可以为第一页保留根 / 。使用“范围”标头，这将是一种奇怪的行为。 HTTP 很久以前就变得过于臃肿了，所以我不建议接受它的每一个标头作为真理。

【讨论】：