The city's DNA Center consumer receives HTTP 429 with a Retry-After value of 30 seconds. What is the robust client action before the next attempt?
Select an answer to reveal the explanation.
Short Explanation
Retry-After is the desk clerk saying 'come back in thirty seconds.' Sleep that long—or longer—then try again. Ignoring the sign and jumping the line makes the limit worse.
Full Explanation
HTTP 429 with Retry-After means the DNA Center (or any API) is asking the client to wait before another attempt. The robust action is to sleep at least that interval—often with additional jitter—then retry inside a bounded budget. Honoring Retry-After reduces thundering herds and matches the server’s stated recovery window of 30 seconds in this scenario.
Ignoring the header and immediately repeating the call worsens rate limiting and can prolong the block. Treating 429 as a permanent 403 and revoking the OAuth client registration confuses temporary throttling with authorization failure and destroys credentials unnecessarily. Switching transport to UDP to “avoid” rate limits is not how REST rate limits work and breaks the HTTP API contract.
Exam caveat: if Retry-After is absent on a 429, still back off with exponential delay rather than spinning; when present, treat its value as a minimum wait. Operational check: parse Retry-After (delta-seconds or HTTP-date), block the next DNA Center attempt until that time elapses, and metric the wait so operators see throttle recovery instead of error storms. When multiple DNA Center consumers share credentials, one client ignoring Retry-After can starve sibling civic jobs—treat the header as a shared courtesy signal, not optional. After waiting, re-resolve any short-lived token if needed, then issue a single follow-up attempt rather than a burst that re-earns 429.