Pagination should always be using 2 parameters: seek and limit.
The seek is the offset into the collection.
The limit is how many to items to acquire.
The seek parameter generalises into any kind of indexable offset that induces a strict partial order on the collection.
So you don't just have to use ordinal offsets, but also things like dates.
Similarly if your seek is a date, then your limit can be a duration.
For HTTP, there are 2 main ways of implementing this:
- In the query parameters
- Using the Range headers
For 1. this is the most common and enables sharing links to paginated content.
For 2. this is less common, but allows more structured/rich metadata for machine to machine communication.
For an SPA plus API app, it could be possible for the SPA to use query parameters while the API uses range headers.
Note that for 1., because of the lack of rich metadata, you have to stick pagination metadata into the content itself.
That means things like links to next or previous, or total count of items available... etc.
A RESTful resource does not entirely have to be discrete.
You can allow the client to specify what kind of representation they would like.
Primarily this is about filters. Filters can be applied to collections, but filters can also apply to singular resources.
If we take a "tree structured" resource like JSON. Then a filter is then a set of paths into the tree from the root.
This allows the server to return only what is needed by the client.
To reduce redundancy, it is often possible to abstract details from a resource into subresources and connect them by references.
So if you have a resource containing 3 different subresources.
You can take them out of the main resource, and have the main resource reference the subresources by IDs.
This has tradeoffs in redundancy and read speed. In some cases you may want the server to resolve the content and embed them in the response.
This a form of batching, pushing the "join" operation to the server side. Or the client can do the "join" operation by querying the other resource endpoints.
Both are acceptable, it depends on the requirements.
If you have the ability to serve partial content via filters. Then you can avoid needing to implement references, and allow any discrete resource to embed subresources.
The "join" is done on the server side, and there's no redundancy either. It also allows you to return an atomic snapshot of multiple resources together.
This concept exists in GraphQL.