Almost each major cloud storage service provider like Google, Box, OneDrive use request parameters to convey pagination info to web services and update response object to further communicate next page info to the client.
Despite of having standard HTTP Headers like Range and Link and custom headers people tend to use query parameters to convey such info.
Using such standard headers to convey pagination info between client and server keeps the standard response unique as we don't need to pass such info via response attributes.
So, what is the best practice to implement pagination in REST APIs? With HTTP Headers or with Query Parameters???
According to the http specs:
A proxy MAY discard a Range header field that contains a range unit it does not understand. That means any intermediate proxy, including caching servers, may throw out your `Range header before it gets to your server.
Link headers have nothing to do with pagination.
A proxy MUST forward unrecognized header fields unless [..] the proxy is specifically configured to block, or otherwise transform, such fields. I read that as a proxy can be configured to block all unrecognized headers, which is the same problem as for
Rangeheaders.Beyond that, using query parameters for pagination (preferably offset/limit) is a standard. If you have a good reason to buck the standard, that's fine. The downside is now everybody who is using your API has to learn your way of doing things in addition to the way everybody else does things. This lowers adoption and increases support calls.