An automation job must list currently open code-enforcement cases from a municipal REST API without changing any records. Which HTTP method should it use?
Select an answer to reveal the explanation.
Short Explanation
GET is the polite ask: 'show me the open cases' without rearranging the filing cabinet. Listing code-enforcement cases is a read—use GET. DELETE, PUT, and PATCH change data; they are not how you fetch a list.
Full Explanation
Listing currently open code-enforcement cases from a municipal REST API without changing records is a read operation, so the automation job should use HTTP GET against the cases endpoint (with appropriate query filters for open status). GET retrieves a representation of the resource or collection and, by REST convention and safe-method semantics, should not mutate server-side case state. That matches dashboards, reconciliations, and reporting jobs that only need visibility into open enforcement work.
DELETE on the cases collection to clear the list before reading fails because DELETE removes resources; clearing cases is destructive and unrelated to listing. PUT that overwrites every case with empty placeholders fails as a full-replace mutation that destroys data rather than reading it. PATCH that marks all cases closed as a side effect of listing fails because PATCH is a partial update method and closing cases is a state change, not a read.
Exam caveat: some poorly designed APIs misuse verbs, but exam-style REST questions expect GET for safe reads, POST for create, PUT for full replace, PATCH for partial update, and DELETE for removal. Also send authorization headers—method choice does not replace access control.
Operational check: call GET on the open-cases route in a non-prod tenant, confirm the response lists cases without altering updated-at or status fields, and ensure automation code never uses DELETE/PUT/PATCH for a read-only inventory step.