This document is also available in these non-normative format: PDF
This document is licensed under
Creative Commons Attribution 4.0 International Public License
This is a draft that could be altered, removed or replaced by other documents. It is not a recommendation approved by TO.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY and MUST in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This document is part of the Nederlandse API Strategie.
The Nederlandse API Strategie consists of a set of distinct documents.
| Status | Description & Link |
|---|---|
| Informative | Inleiding NL API Strategie |
| Informative | Architectuur NL API Strategie |
| Informative | Gebruikerswensen NL API Strategie |
| Normative | NLgov REST API Design Rules (ADR v2.2) |
| Normative | Open API Specification (OAS 3.0) |
| Normative | NLgov Assurance profile for OAuth 2.0 |
| Normative | Digikoppeling REST API koppelvlak specificatie |
| Normative module | GEO module v1.0 |
Before reading this document it is advised to gain knowledge of the informative documents, in particular the Architecture.
This document describes the Pagination module, containing rules for paginating results from large datasets.
This document is a module as part of the API Design Rules.
Resource collections can be unreasonably large for a single response. With pagination, a segment of the resources can be returned while providing a method to retrieve other segments (or "pages"). This module provides design rules which attempt to strike a balance between enhanced predictability for clients and flexibity to suit different data collection types.
A distinction between two categories of collections is used throughout this module: static and dynamic.
Static collections are stable or at least unlikely to change while a client is retrieving segments of the resources. Page-number pagination would suffice for these collections. If no mutation occured between retrieving pages, sequential pages will have no gaps or overlap, e.g. if item no. 100 is the last of a page, item no. 101 will be the first item on the next page.
If a resource collection is not completely static, no pagination method is reliable for synchonisation.
Dynamic collections see frequent mutations. While a client jumps from one page to the next an item may have been inserted or removed in the previous pages causing a shift that results in an overlap or a gap, respectively. At the cost of complexity, cursor pagination is more robust by providing a pointer to a listed item for page boundaries which remain consistent even if collection shifts.
In order to support both collection categories, this module allows two pagination formats: page-number pagination (using page and pageSize) and cursor pagination (using cursor and limit).
/pagination/format: Use standard pagination format
A paginated request MUST use one (and only one) pagination method from the following list:
page and pageSize:
page: requested page number (1-based)
pageSize: maximum number of items to return per page
cursor and limit:
cursor: opaque pointer to current position in dataset
limit: maximum number of items to return per page
An endpoint MAY define additional aliases such as, but not limited to, size or offset for backwards compatibility.
The defined formats cover the main usage patterns of pagination with the most commonly used names for query keys.
/pagination/links: Use a Link header for navigation
A paginated response MUST include an HTTP Link header [RFC8288] for navigation to other result segments according the following list:
first, prev, next, and last
next and prev
A Link header provides clients a convenient and consistent method of navigation.
The link relation types are part of the Link Relations registry maintained by IANA.
/pagination/sorting: Use deterministic ordering in paginated responses
Items in a paginated response MUST use deterministic ordering.
If the order can change beyond the influence of the client, items are likely to be missed or appear multiple times while traversing pages.