A 311 intake bot posts a new service request and the API responds with HTTP 201. What does that response communicate?
Select an answer to reveal the explanation.
Short Explanation
201 is the clerk stamping 'filed' on the new 311 slip—resource exists now. That is create success, not auth failure or timeout. Do not delete a ticket that just got created.
Full Explanation
When a 311 intake bot posts a new service request and the API responds with HTTP 201, the server is communicating that the service request resource was successfully created. 201 Created is the standard success status for a new resource under REST conventions: the intake succeeded, an identifier typically exists, and automation should proceed to confirmation, routing, or resident notification—not to auth recovery or deletion workflows.
Unauthorized retry-with-new-password fails by concept because authentication failures are 401 (or related auth challenges), not 201. Gateway timeout before storage fails because timeouts and upstream unavailability surface as 504/503/5xx-class conditions, not as 201. Permanently deleting the ticket because creation failed fails twice: 201 means creation did not fail, and deleting a just-created 311 request would discard a valid municipal work order the resident expects to be tracked.
Exam caveat: some APIs return 200 with a created body; exams still treat 201 as the clearest “created” signal. Also distinguish 201 (new resource) from 200/204 on updates. Do not assume Location header presence is optional to ignore in production clients even if the multiple-choice focus is status meaning.
Operational check: on 201, persist the returned request id, show the resident a confirmation, avoid duplicate POST retries that could create double tickets unless idempotency keys are in play, and monitor for sudden drops from 201 to 401/503 which indicate auth or capacity regressions on the 311 intake path.