-
Notifications
You must be signed in to change notification settings - Fork 0
Pagination
The default will use sort and where to automatically browse to the next page. If you're sorting by name+asc, the response contains the first 100 results and the last item is the name Frank, the next page will be a filter where=name>Frank.
The Pagination category will be configurable. We'd want to support:
- The default
whereandsorttechnique. - A classic
page=2parameter. Maybe withsize=100parameter. - Another classic
limitandoffsetparameters. Orskipandtake.
The Endpoints library will use the page info to return a Link header that can be followed to get the next page.
Link: <https://api.yourapplication.com/people?sort=name+asc&where=name%3EFrank>; rel="next"This will most likely need to tie into the ResponseGenerator to get page info in the response body. Something like:
GET /people?sort=name{
items: [
{ id: 1, name: "Aaron" },
...
{ id: 1234, name: "Frank" },
],
page: {
next: "/people?sort=name&where=name>Frank"
}
}Automatically finding a query to get the page before could prove to be difficult.
One option is to use a new querystring param to specify that the results are paged to the end of the sort. For example, on the >Frank page:
GET /people?sort=name&where=name>Frank{
items: [
{ id: 1235, name: "Fred" },
...
{ id: 2345, name: "Jo" },
],
page: {
prev: "/people?where=name<Frank&sort=name+asc&page=end",
next: "/people?where=name>Jo&sort=name+asc"
}
}Another option is to include it as a third sort modifier. Thought of like "sort descending, then limit results, then sort ascending". This also forces a sort order to be specified this way, which resolves the problem where with SQL servers that don't use LIMIT and OFFSET.
prev: "/people?where=name<Frank&sort=name+asc+end"Or perhaps to add further control, a parameter to specify sort instructions after the limiting:
prev: "/people?where=name<Frank&sort=name+desc&postsort=name+asc"