How to undo a DELETE action and comply with RESTful standards?

Question

I am creating a project around my own API and everything is working fine so far, but I would like to introduce UNDO actions for DELETE.

So far, DELETE works like this:

DELETE / contacts /: id

My initial one though for UNDO is to call the same DELETE on the same URL that cancels the remote state (if that contact is in the delete state), but I don't know if it is good or not.

I am reading this post that looks similar, but the “checkout” part gives an answer to something else from what I'm looking for.

Is my suggestion good or is there a better way?

Thank you for your help.

Answer 1

If you deleted the resource using DELETE , subsequent requests to the resource should return 404 NOT FOUND or 410 GONE , because there are no more resources to receive requests.

If this is acceptable and you have an available state, the simplest answer is to simply recreate the resource by issuing the PUT at the remote URL of the resource. Semantically, this creates a new resource, replacing any existing state, and does not cancel the deletion.

Another simple solution is to acknowledge that you are not actually deleting the resources and simply changing your state in any way to show that they are archived. This means that you cannot use the verb DELETE , but you can issue PUT or POST requests to a resource to change between archived and active states.

If you want to save DELETE as a means of deleting records, then the option should allow access to the archived resource using the special value show-archived :

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

Specifying this on an archived resource returns 200 to an archive resource instead of one of the 40X codes. This is a little dirty, because your resources now have a “superstate” problem of appearance and existence, and it does not exist depending on how you observe them. However, this means that you can query the resource to update its status:

 PUT /contacts/<id>?show-archived=true State=Active ... all other unchanged fields ... 

Answer 2

I would personally do UNDO DELETE a PUT on the resource if the deletion state is part of the view, or POST on the action if not.

That action will look like this:

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

But this is, as it seems to me, the most consistent with RESTFul .