Problem/Motivation
The current restrictions in the JSON API pagination make it difficult for developers to implement paginations. These restrictions were set because of architectural limitations of Drupal.
Responses don't necessarily contain the number of items the client requested, even when items would be available in the backend. That means that pages returned by JSON API cannot be mapped to pages shown in the UI since a single page might consist of items from multiple JSON API pages. As a result, for the client to be able to show page 4 would require that it has retrieved content since the beginning of the list until the client has enough content to display the page 4.
Performance issues. For example, user doesn't have permission to view users on a site with 10,000 users. To be able to tell the user that there's no users they can access, the client would first have to request all the content.
Lack of reliable count. Most pagination libraries and UI implementations require total count. This is also blocker for being able to implement "full pager" with links to specific pages.
Missing first/last links. Currently, implementing first/last page links on the client without running into serious performance issues in the client is not possible.
It is good to note that the API works well for infinite scroll use case, but not for typical pagination. The pagination method is chosen based on the use case which means that it doesn't seem like a valid restriction to only support one pagination method.
Proposed resolution
-
Remaining tasks
-
API changes
-