问题
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
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:
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units.
Finally the spec ends with this statement:
HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges.
- Is any other unit than byte allowed ?
- If HTTP/1.1 was designed to allow app to not depend on range, what are the real drawback about relying on it for an API ?
NB: I don't care about "browsability".
回答1:
Here the answers that I gently borrowed from this question thanks to @ptidel: Content-Range header - allowed units?.
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
While the second statement has been made for producing HTTP request.
Finally, the whole comment from Ferenc Mihaly summarizes perfectly the situation:
I conform to the HTTP spec when I'm sending [a custom range unit] and they conform to HTTP when they ignore it
WebDAV uses HTTP extensions correctly, IMO, but rarely works over the Internet for exactly this reason
回答2:
Most of the times you don't want to show all of your items by default. With ?p=2 style pages it's ok to reserve root / for first page. With "Range" header it would be strange behavior. HTTP became overbloated long time ago so I wouldn't recommend to accept every its headers as Truth.
来源：https://stackoverflow.com/questions/21765555/why-most-api-paginations-do-not-rely-on-http-range-header