A monitoring platform calls an on-premises controller that follows link-based paging, where each JSON body carries a links.next URL until the final page. The service also answers HTTP 429 with a Retry-After header containing a delay in seconds whenever a client sends requests faster than its stated limit. You need a loop that collects every record without tripping the throttle. Which request-handling pattern satisfies both the paging and rate-limit rules?

The correct pattern honors two independent parts of the service contract. Link-based pagination means each response supplies the URL for the next page in its links.next field; follow that URL rather than constructing page positions, and stop when no next link is provided. Rate limiting is signaled separately: on HTTP 429, read Retry-After as a delay in seconds, wait for that full interval, then retry the throttled request before continuing. Fixed-offset pagination with a steady delay uses an offset scheme the service does not specify, so it can miss records or request pages incorrectly even if it handles 429 responses. Back-to-back retries after throttling disregard the server’s requested wait and can trigger further 429 responses. A fixed two-second sleep is also wrong because it substitutes a guessed delay for the value the server supplied; the required wait may be shorter or longer. Exam caveat: pagination instructions do not control retry timing, and throttle instructions do not determine how to find the next page—apply both rules independently. Practical check: confirm each successful response’s next URL is followed, the loop ends when that link is absent, and every 429 is followed by a wait matching its Retry-After value before retrying.