The nightly job that exports 5,000 device records from a paginated REST API often stalls or ends incomplete: the service returns 500 records per page, throttles bursts with 429 plus Retry-After, and occasionally returns an internal server error. Which change to request handling is most likely to improve completeness and accuracy?
Select an answer to reveal the explanation.
Short Explanation
You’ll improve completeness by following each page marker in order and honoring Retry-After when the service returns 429. If a temporary 500 occurs, retry a limited number of times with an appropriate delay; this improves your chances, though it can’t guarantee every run succeeds.
Full Explanation
The approach that follows each page marker in sequence, honors Retry-After on 429 responses, and retries transient errors a limited number of times is most likely to improve completeness and accuracy. Pagination lets you collect the full set of records, respecting Retry-After responds to the service’s throttling signal, and bounded retries give temporary server errors a chance to recover without risking endless attempts. Following page markers and waiting for Retry-After but failing immediately on a transient 500 can leave the export incomplete even when the error is recoverable. Following markers, honoring Retry-After, and retrying transient failures while requesting 1,000 records per page ignores the stated 500-record page limit; the service may reject or cap the request, so that page size cannot be relied on to retrieve the expected records. Following markers and honoring Retry-After but treating a 500 as terminal also leaves no recovery path for a temporary internal error. Exam caveat: retries should be limited and appropriate for the request, since unbounded retries can prolong a job or add to service load. Practical check: compare the completed export’s unique record count with the expected total, and inspect page markers, response codes, and retry attempts to confirm that every page was retrieved.