How to undo a DELETE action and respecting RESTful standards?

Question

I'm building a project around my own API, and everything works fine so far, but I'd like to introduce UNDO actions for DELETE.

So far, the DELETE works this way:

DELETE /contacts/:id

My initial though for UNDO is to call the same DELETE on the same url, which would cancel the deleted state (if this contact is in deleted state), but I don't have any idea if this is a good way or not.

I read this post that looks similar, but the "checkout" part gives the answer something else from what I am looking for.

Is my suggestion good or is there a better way ?

Answer 1

I personally would make the UNDO DELETE a PUT over the resource if the deletion state is part of the representation, or a POST on an action if not.

That action would look like:

POST /contact/id/action/[recover|reactivate] (or whatever you think is more descriptive for the action).

But this is just the way I think is most RESTFulcompliant.

Answer 2

If you have removed a resource using DELETE subsequent requests to the resource should return 404 NOT FOUND or 410 GONE because there is no longer a resource there to accept requests.

If acceptable and you have the state available, the most simple answer is to simply re-create the resource by issuing a PUT at the removed resource's URL. Semantically this creates a new resource, replacing any existing state, not really undoing the delete.

Another simple solution is to admit that you're not actually deleting resources and merely change their state in some way to show they're archived. It means you can't use the DELETE verb but you can issue PUT or POST requests to the resource to change between archived and active states.

If you want to preserve DELETE as your means of removing the records, then an option is to make it possible to access an archived resource by use of a special show-archived value:

GET /contacts/<id>?show-archived=true

Specifying this on an archived resource would return a 200 on an archived resource instead of one of the 40X codes. It's a bit mucky, because your resources now have a "superstate" problem of appearing both to exist and not exist depending on how you observe them. It does however mean that you can make a request to the resource to update its state:

PUT /contacts/<id>?show-archived=true

State=Active
... all other unchanged fields ...