An open-data portal must retire an obsolete dataset registration so clients stop discovering it. Which REST method should the automation use?
Select an answer to reveal the explanation.
Short Explanation
You can think of DELETE like taking a closed park off the city map—not leaving a sticky note that says it might be closed. Removing the dataset registration handle stops discovery; listing metadata or adding a comment leaves the old entry discoverable.
Full Explanation
Retiring an obsolete open-data registration is a CRUD delete task: the registry must stop advertising a handle clients should no longer discover. Use DELETE on the dataset registration resource; this standardized method removes the named resource so subsequent list and read operations no longer return it. The handle then disappears from normal catalog searches, harvest feeds, and developer portals, meeting the retirement goal. GET fails because it only lists metadata and does not change registration state, so the handle remains discoverable. PUT fails because overwriting the title while keeping the old handle live still publishes the entry, and clients can continue resolving that handle. PATCH fails because appending a comment that the dataset might be outdated leaves the registration published; a warning is not retirement. Exam caveat: deleting the registration handle does not mean deleting underlying storage blobs, archival copies, or legal retention sets. Open-data programs may keep cold archives while removing catalog discoverability, so do not equate portal retirement with wiping historical data or treat title and comment updates as equivalent to DELETE. Practical check: after DELETE, verify the handle is absent from catalog list and search APIs, harvest clients no longer receive it in incremental feeds, and dependent apps get the expected 404/410 on its old URI. Record the archival location for compliance without re-exposing the dataset through the live registration path.