RESTful delete strategy

Question

Let\'s say I have a resource that can have two different behaviors when delete is called

1. The resource is deleted.
2. The resource is moved to the recycl

Answer 1

DELETE should delete the item, no questions asked.

Sadly, there is no 'MOVE' request in HTTP. POST is usually intended for creating content, PUT is more modifications.

So I would suggest you you do something like PUT /myresource with some form of meta-data or a json string along the lines of { "recycle":"true" } to indicate that you want to 'recycle' it.

Answer 2

Why not? You are already passing a parameter to identify which resource, so send another one to establish a different course of action. IMO, it is perfectly RESTful.

Answer 3

You could also implement 2. as a POST request instead of DELETE.

POST /myresource

recycle-bin=true...

As in all you're doing is updating the resource to indicate that it is in the recycle-bin.

EDIT: changed method from PUT to POST given a PUT must enclose a complete replacement (or addition) of the resource, whereas clearly here we are only updating a part of the resource.

Answer 4

A pure REST strategy should prefer non changing resources. In my opinion, you are not changing the resource by appending a parameter, so it sounds like good strategy to me.

If you were to perform the same action like so:

DELETE /myresource.force

that would act like another resource, which wouldn't be optimal.

Answer 5

Your idea is fine, but I think a custom request header would be a little more appropriate. Query parameters are better suited to, well, parameters.

A custom request header would look something like this:

DELETE /myresource
X-Really-Delete: Yup