A public-works app consumes a Cisco REST API that paginates with a Link header including rel="next". How should the client construct follow-on requests?
Select an answer to reveal the explanation.
Short Explanation
Follow the “next chapter” ribbon the librarian tucked in the book until there is no ribbon left. When the API pages with Link rel=next, call that URL; stop when next disappears.
Full Explanation
Link-header pagination is driven by the server-advertised URL, not by client inventiveness. When a public-works app consumes a Cisco REST API that paginates with Link including rel="next", the client should GET the URL from rel="next" until that relation is absent. Each page’s Link header tells the consumer exactly where the following window lives—including host, path, and query—so campus inventory walks stay complete without guessing page numbers.
Stopping after the first 200 and assuming a single page always contains the full collection fails for any result set larger than one page and silently under-reports assets. Inventing a new path by appending /page/2 regardless of what Link returns fails when the API uses cursors, different query shapes, or opaque URLs. Switching to WebSocket streaming because Link headers cannot drive a request loop fails by concept: Link-based loops are a standard REST pagination pattern.
Exam caveat: also honor rel="prev" when walking backward; stop when rel="next" is missing even if the last page looks “full.” Do not require a page token field when Link alone is the contract.
Operational check: against a multi-page fixture, confirm the client performs N GETs following each rel="next" and stops when Link lacks next, with the aggregated item count matching the platform total.