Mapping an HTTP DELETE request entity body to a method parameter

Question

I am building a REST API using JAX-RS . In angular front-end, I am sending the object to be deleted in the body of the HTTP request (JSON format). Now I need a way to map this HTTP DELETE body request which is containing the object that needs to be deleted to a local variable in the REST method. For instance, on SPRING I did this by simply annotating an object variable with @RequestBody .
I was checking oracle's javaEE7 docs but the examples there are really basic and don't include complex objects, also the different tutorials that I found elsewhere were on the track of simple delete requests mapping a simple id with @PathParam .

Maybe before this question, the first question I should ask is whether sending the object in an HTTP's request body is at all a good approach? I was reading some articles which designated it as not such a good practice, although it is not explicitly forbidden. What would be the disadvantages of this approach? I remember while I was researching about this method in SPRING , I read somewhere that malicious attacks could be possible by specially crafted user inputs (the persistence framework that I am using is JPA, EclipseLink). Would it perhaps be better to map the primary key on a series of @Path variables and then map them using @PathParam ?

So to sum up, first of all, is this a good approach? And how can I read the object in the HTTP's request body? Some pointers would be highly appreciated!

Answer 1

Unlike Spring MVC, JAX-RS does not define any annotation for the request payload.

The JAX-RS approach is slightly different: the value of the parameter not annotated with any @***Param annotations is mapped from the request entity body. Such parameter is called entity parameter .

---

The first question I should ask is whether sending the object in an HTTP's request body is at all a good approach?

Please refrain from doing that, as it's not how DELETE is supposed to work.

Find below a quote from the RFC 7231 , the document that currently defines the semantics and content of the HTTP/1.1 protocol:

A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.

For interoperability, I advise you to stick to the standards as much as you can. And you definitely shouldn't be require to send any payload to identify the resource to be deleted.

---

Its primary key is 8 fields long.

The URI , which stands for U niversal R esource I dentifier, is meant to identify a resource .

As you have a bunch of fields that, in conjunction, identify a resource, I advise you to rethink your application design. You could, for example, introduce some sort of unique value to identify your resources. Have a look at UUID .

Answer 2

With JAX-RS you don't need a something like a @RequestBody.

You can simply add the class as parameter and it will be filled with the request body.

In you case passing the data in the body makes sense but how does your URL look like? As with REST you should have resources that are addressable by a URL