为什么大多数 API 分页不依赖于 HTTP 范围标头

Question

我搜索了很多，但我找不到这个问题的好答案。作为 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 旨在允许实现不依赖于范围知识的应用程序。

• 除了字节之外，是否允许任何其他单位？
• 如果HTTP/1.1被设计为允许应用程序不依赖于范围，那么依靠它作为API的真正缺点是什么？

注意：我不在乎"可浏览性"。

Answer 1

在这里，由于@ptidel，我从这个问题中轻轻借用了答案：内容范围标题 - 允许的单位？

首先，本草案 HTTP/1.1 第 5 部分：范围请求和部分响应中提出了自定义单位

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

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

虽然第二个语句是为生成 HTTP 请求而做出的。

最后，费伦茨·米哈里的整个评论完美地总结了这种情况：

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

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

Answer 2

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