A police records bureau’s scripts call a network controller API and sometimes receive HTTP 401, 429, or 5xx responses. Which client behavior is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Controller APIs talk in status codes the way dispatch talks in ten-codes—401 means fix the badge, 429 means slow down, 5xx means the other end is sick. Refresh auth, back off, and only escalate when it keeps failing. Blind hammering just makes the outage louder.
Full Explanation
Police records scripts calling a network controller API must handle HTTP 401, 429, and 5xx distinctly: treat 401 as credential/session refresh, back off on 429 and 5xx with limited retries, and surface persistent failures. That client behavior prevents credential storms and silent data corruption while respecting controller rate limits. Robust HTTP semantics are part of EI programmability operations.
Retrying every failure immediately in a tight loop until killed amplifies outages. Mapping all non-200 responses to silent success hides incidents. Disabling TLS and switching to cleartext HTTP to avoid status codes worsens security and does not fix client logic.
Exam caveat: retry budgets and jittered backoff should be policy-driven; infinite retries are never acceptable for municipal batch jobs. Operational check: simulate 401/429/5xx in a mock, confirm refresh/backoff/alert paths, then run against lab controller fault injection if available. Open tickets automatically only after retries exhaust with error context attached. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.