The Potential Pitfalls of Pagination
The Potential Pitfalls of Pagination
Pagination is a core part of many APIs, but many methods have hidden pitfalls. This post explores these common issues.
You're viewing a single thread.
In time-based pagination, the suggested fix to lots of data in a selected timespan is:
simply adding a limit to the amount of records returned (potentially via a query parameter) transparently solves it.
This means clients can't see all the results, unless you add a way to view other pages of data, which is just pagination again. Or is the intended design that clients view either the first x results (the default) or view all results?
The problem with articles like OPs and others is that they don't allow custom sorting, which is often a requirement, e.g. interfaces that present the data in a table, where column headers can be clicked to sort.
Regarding your first paragraph, this results limit is per page. To get the next page, you take your timestamp of the last item and use it in
from_time, or whatever you've called it. It's still a pagination technique.Regarding custom sorting, some of the techniques in the article can do this, some of them can't. Obviously timestamp based pagination can't, however the ID-based pagination that I mentioned can.