REST architecture for multiple deletions?

Question

I am sending a delete request as a server:

@RequestMapping(value = "/user/{userId}", method = RequestMethod.DELETE) 

to delete one user. However, what to do when multiple users want to be deleted? I want to obey the REST architecture, but I want other ways to send multiple delete requests?

PS: This is a suitable way:

 @RequestMapping(value = "/user", method = RequestMethod.DELETE, headers = "Accept=application/json") public void deleteUser(HttpServletResponse response, @RequestBody String users) throws IOException { ... } 

Answer 1

since the rest is a resource-oriented arch.

try creating a higher level domain object that represents a resource of multiple users,

delete on this object.

may be

 @RequestMapping(value = "/users/expired", method = RequestMethod.Delete) 

Subbu Allamaraju, oreilly, the great web service cookbook, talks about this topic:

• chapter 11.10 how to handle similar resources;
• chapter 11.11 how to start a batch operation;
• chapter 11.12, when to use a message to combine multiple requests;
• chapter 11.13 how to support a batch request

Answer 2

I am familiar with REST enough to understand that using POST to achieve DELETE is a deviation from REST compliance. I can’t say that this is the right rule.

I suspect that this may have something to do with the ability of the API agnostic toolkit (for example, the dev tool, which makes such assumptions about the state of implementation based on givens about the definitions of verbs without needing to be configured to understand what specific API methods are) or the impossibility of returning fine-grained errors in the event of a partially successful deletion, but these are only guesses and not very important for this issue.

Swanliu's answer means using URLs that represent the grouping construct as the target of removal, but the above example / users / expired offers a fixed (and possibly systemic) grouping. The more user-oriented case of an arbitrary collection still requires listing at some point to achieve.

Issuing an N DELETE for a group of size N is not attractive, either due to complex latency or lack of atomicity, but REST DELETE can focus on only one resource.

I think the best practice implied by Swanliu's answer might be to define a POST operation that can create a resource that will become the new parent-guardian of the objects to be deleted. POST can return the body, so the system in question can create a unique identifier for this resource without a domain for it and return it to the client, which can deploy and issue a second request for DELETION. The resource created by POST is short-lived, but targeted — it destroys cascades for domain objects that were the desired goal of the bulk delete operation.

 > POST /users/bulktarget/create > uid=3474&uid=8424&uid=2715&uid=1842&uid=90210&uid=227&uid=66&uid=54&uid=8 > ... < ... < 200 OK < ae8f2b00e > DELETE /users/bulktarget/ae8f2b00e > ... < ... < 200 OK 

Of course, two network exchanges are less desirable than one, but given that fewer deleted files are two objects and will require two DELETE operations to handle without any problems, it seems like a fair compromise - think about it to get every object outside the second free.

Answer 3

My understanding of REST is exactly what you should do. If there is an alternative that I would also like to know :)

If you do not want to send multiple removal requests, then you need to create a rougher api. (which is why most of the APIs are RESTful there, not REST)

By the way, I think you need RequestMethod.DELETE?

Answer 4

AFAIK basic REST is designed to work with a single resource. I would go with POST to the /user/ resource and a special deleteUsers tag containing identifiers for deletion.