An application uses the Meraki Dashboard API to fetch the list of networks for an organization. The API response includes a Link header with rel='next' pointing to the next page. Which pagination method is the API using?
Trap 1: Cursor-based pagination using startingAfter/endingBefore parameters
startingAfter/endingBefore are Stripe-style cursor parameters passed in the query string; Meraki instead returns a complete next-page URL in the Link header. It is tempting because cursor pagination also follows links, and would be correct if the client supplied an object ID cursor rather than consuming the server-provided rel='next' URL.
Trap 2: Offset-based pagination using page and perPage parameters
Offset pagination would require page and perPage query parameters and a response exposing total counts; here the next page arrives solely as a Link header URL. It is tempting because page/perPage is the classic Meraki style, and would be correct if the client incremented page numbers rather than following rel='next' links.
Trap 3: Token-based pagination using a nextPageToken parameter
Meraki's Link header with rel='next' supplies a full URL, not a nextPageToken parameter, so no token is parsed from the body. It is tempting because token pagination is common in other Cisco and cloud APIs, and would be correct where responses embed an opaque continuation token instead of a Link header.
- A
Cursor-based pagination using startingAfter/endingBefore parameters
Why it fails: startingAfter/endingBefore are Stripe-style cursor parameters passed in the query string; Meraki instead returns a complete next-page URL in the Link header. It is tempting because cursor pagination also follows links, and would be correct if the client supplied an object ID cursor rather than consuming the server-provided rel='next' URL.
- B
Offset-based pagination using page and perPage parameters
Why it fails: Offset pagination would require page and perPage query parameters and a response exposing total counts; here the next page arrives solely as a Link header URL. It is tempting because page/perPage is the classic Meraki style, and would be correct if the client incremented page numbers rather than following rel='next' links.
- C
LinkHeader-based pagination
The response's Link header containing rel='next' supplies the URL for the following page. The client follows that link rather than constructing offsets or cursors itself, which is the defining characteristic of Link-header-based pagination in the Meraki Dashboard API.
- D
Token-based pagination using a nextPageToken parameter
Why it fails: Meraki's Link header with rel='next' supplies a full URL, not a nextPageToken parameter, so no token is parsed from the body. It is tempting because token pagination is common in other Cisco and cloud APIs, and would be correct where responses embed an opaque continuation token instead of a Link header.