A Cisco list API returns a nextPageToken cursor instead of numeric offsets. How should the consumer request the following page?
Select an answer to reveal the explanation.
Short Explanation
A coat-check token is not a math worksheet—you hand the same stub back. With cursor pagination, send the opaque nextPageToken as given; decoding or inventing offsets skips or duplicates rows.
Full Explanation
Cursor pagination treats nextPageToken as an opaque server capability. When a Cisco list API returns a nextPageToken, the consumer requests the following page by sending that value back exactly as provided—typically as a query parameter the docs name—without decoding or reinventing it. Opacity lets the platform encode positions, filters, and consistency marks that clients must not reverse-engineer.
Decoding the token locally and converting it into a homemade offset arithmetic sequence fails the opacity contract and breaks when the token format changes. Incrementing a client-side counter and sending it as offset even though the API never advertised offsets fails by mixing pagination styles. Ignoring the token and repeating the first request until items start duplicating fails completeness and burns quota on page one forever.
Exam caveat: tokens may expire or be single-use across long pauses—handle documented invalid-token errors by restarting the list walk. Do not log tokens if they embed sensitive filter material.
Operational check: capture the token from page one, send it unchanged on page two, confirm new items arrive without overlap (or with documented overlap only), and stop when nextPageToken is absent.