tags:

views:

588

answers:

4

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 recycle bin.

How would model it in a REST compliant way?

I thought about the following solution:

DELETE /myresource

moves the resource to the recycle bin (default behavior)

DELETE /myresource?force-delete=true

forces delete on the resource.

Is that REST compliant? I have never seen query parameters in the URL when calling DELETE, is that OK?

+1  A: 

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.

Swanand
+4  A: 

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.

ern
+3  A: 

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
Avi Flax
+1  A: 

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.

rojoca