Reputation: 39859
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 ?
Upvotes: 7
Views: 2611
Reputation: 39625
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 ...
Upvotes: 7
Reputation: 8432
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 RESTFul
compliant.
Upvotes: 1