Why use two step approach to deleting multiple items with REST?

Question

We all know the 'standard' way of deleting a single item via REST is to send a single DELETE request to a URI `example.com/Items/666`. Grand, let's move on to deleting many at once. As we do not require atomic deleting (or true transaction, ie all or nothing) we could just tell the client 'tough luck, make many requests' but that's not very nice is it. So we need a way to allow a client to request many 'Items' be deleted at once.From my understanding, the 'typical' solution to this problem is a 'two step' approach. First the client POSTs a list of item IDs and is returned a URI such as `example.com/Items/Collection/1`. Once that collection is created, they call DELETE on it.Now, I see that this works just fine, except to me, it is a bad solution. Firstly, you are forcing the client to make two requests to accommodate the server. Secondly, 'I thought DELETE was supposed to delete an Item?', shouldn't calling DELETE on this URI effectively cancel the transaction (it's not a true transaction though), how would we even cancel it? Really would be better if there was some form 'EXECUTE' action, but I can't rock the boat *that* much. It also forces the server to have to consider 'the JSON that was POSTed looks more like a request to modify these Items, but the request was DELETE... so I guess I will delete them'. This approach also starts to impose a sort of state on the client/server, not a true state I will admit, but it is sort of.In my opinion, a better solution would be to simply call DELETE on `example.com/Items` (or maybe `example.com/Items/Collection` to imply this is a multiple delete) and pass JSON data containing a list of IDs that you wish to delete. As far as I can see, this basically solves all the problems the first method had. It is easier to use as a client, reduces the work the server has to do, is truly stateless, is more semantic.I would really appreciate the feed back on this, am I missing something about REST that makes my solution to this problem unrealistic? I would also appreciate links to articles, especially if they compare these two methods; I am aware this is not normally approved of for SO. I need to be able to disprove that only the first method is truly RESTfull, prove that the second approach is a viable solution. Of course, if I am barking up the wrong tree do tell me.

Answer 1

This seems like one of those dogmatic vs. pragmatic things. REST is great, and utilizing the HTTP verbs to express intent is a great thing to do, but as you've pointed out here, adhering to singleton entity operations exclusively hits a wall of practicality at a certain point. I don't think you're barking up the wrong tree at all - I've seen very few systems of any consequence in the real world that absolutely adhere to RESTful principles.

What you're proposing is perfectly reasonable in terms of efficiency/maintainability/etc.

Points are seldom awarded for adhering to dogma :)