CODEWITHSUNDEEP
rest
LiorH
LiorH

Reputation: 18824

RESTful delete strategy

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?

Upvotes: 11

Views: 2910

Answers (5)

thecoshman
thecoshman

Reputation: 8660

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.

Upvotes: 2

rojoca
rojoca

Reputation: 11190

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.

Upvotes: 2

Avi Flax
Avi Flax

Reputation: 51849

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

Upvotes: 11

ern
ern

Reputation: 1512

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.

Upvotes: 4

Swanand
Swanand

Reputation: 12426

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.

Upvotes: 2

Related Questions