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

问题描述

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

I've searched a lot but I can't find a good answer to this question.Being a HATEOAS aficionado, I would think that this header fit perfectly:

    Range: item=1-20/100

在 HTTP 规范中，我不明白一些矛盾":范围单位可以接受other-range-unit"...

In the HTTP spec, I don't understand some "contradictions":The range unit can accept "other-range-unit"...

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

...但规范是后来明确的:

... yet the spec is later explicit:

HTTP/1.1 定义的唯一范围单位是字节".HTTP/1.1 实现可能会忽略使用其他单位指定的范围.

最后，规范以这个声明结束:

Finally the spec ends with this statement:

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

• 是否允许使用除字节以外的任何其他单位?
• 如果 HTTP/1.1 旨在允许应用不依赖范围，那么依赖它来获取 API 的真正缺点是什么?

注意:我不关心可浏览性".

NB: I don't care about "browsability".

推荐答案

这里是我从这个问题中轻轻借用的答案，感谢 @ptidel:Content-Range 标头 - 允许的单位?.

Here the answers that I gently borrowed from this question thanks to @ptidel: Content-Range header - allowed units?.

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

First, custom units are proposed in this draft HTTP/1.1, part 5: Range Requests and Partial Responses

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

Second, there is a subtle difference, the first statement has been made for parsing purpose

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

虽然第二个语句已用于生成 HTTP 请求.

While the second statement has been made for producing HTTP request.

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

Finally, the whole comment from Ferenc Mihaly summarizes perfectly the situation:

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

WebDAV 正确使用 HTTP 扩展，IMO，但正是由于这个原因，很少在 Internet 上工作

WebDAV uses HTTP extensions correctly, IMO, but rarely works over the Internet for exactly this reason

这篇关于为什么大多数 API 分页不依赖于 HTTP Range 标头?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！