API Design Rules Module: Pagination

Logius Guide
Draft

This version:
https://logius-standaarden.github.io/API-mod-pagination/
Latest published version:
https://gitdocumentatie.logius.nl/publicatie/api/mod-pagination/
Latest editor's draft:
https://logius-standaarden.github.io/API-mod-pagination/
Previous version:
https://gitdocumentatie.logius.nl/publicatie/api/mod-pagination//
Editor:
Logius Standaarden (Logius)
Author:
Logius Standaarden (Logius)
Participate:
GitHub Logius-standaarden/API-mod-pagination
All issues
File an issue
Commit history
Pull requests

This document is also available in these non-normative format: PDF


Status of This Document

This is a draft that could be altered, removed or replaced by other documents. It is not a recommendation approved by TO.

Conformance

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.

Abstract

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.

1. Introduction

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.

1.1 Static collections

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.

1.2 Dynamic collections

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.

1.3 Pagination formats

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).

2. Design rules

2.1 Summary

Design rules are technical rules, which should be tested automatically, and functional rules, which should be considered when designing and building the API.

List of technical rules

List of functional rules

2.2 Rules

technical

/pagination/format: Use standard pagination format

Statement

A paginated request MUST use one (and only one) pagination method from the following list:

  • Page-number pagination using query keys page and pageSize:
    • page: requested page number (1-based)
    • pageSize: maximum number of items to return per page
  • Cursor pagination using query keys cursor and limit:
    • cursor: opaque pointer to current position in dataset
    • limit: maximum number of items to return per page
Note

An endpoint MAY define additional aliases such as, but not limited to, size or offset for backwards compatibility.

Rationale

The defined formats cover the main usage patterns of pagination with the most commonly used names for query keys.

How to test
functional

/pagination/sorting: Use deterministic ordering in paginated responses

Statement

Items in a paginated response MUST use deterministic ordering.

Rationale

If the order can change beyond the influence of the client, items are likely to be missed or appear multiple times while traversing pages.

A. References

A.1 Normative references

[ADR]
API Design Rules. Jasper Roes; Joost Farla. Logius. URL: https://gitdocumentatie.logius.nl/publicatie/api/adr/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8288]
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
Logius Guide - Draft