0

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???

chetan choulwar
  • 305
  • 1
  • 14

1 Answers1

0

According to the http specs:

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.

Community
  • 1
  • 1
Eric Stein
  • 13,209
  • 3
  • 37
  • 52
  • Are you saying the HTTP spec is _not_ a standard, but using query parameters _is_? Where is the latter defined as a standard? – jaco0646 Aug 30 '18 at 16:42
  • @jaco0646 I'm saying that the HTTP spec says you shouldn't use headers for this purpose, and also that common practice is to use query parameters. – Eric Stein Aug 30 '18 at 22:56
  • 1
    @EricStein Proxy will discard/ignore unrecognized headers for HTTP and not for HTTPS (I read it somewhere, please correct me if I'm wrong) And regarding the Link header, GitHub is actively using them for pagination [link](https://developer.github.com/v3/#pagination) whereas leading cloud storage providers like Google, Microsoft, Box, etc are following HATEOS principle for conveying next page info i.e. via response attributes – chetan choulwar Aug 31 '18 at 05:11