dev@glassfish.java.net

Jersey (REST, not Shore) question about _at_DELETE

From: Bobby Bissett <bobby.bissett_at_oracle.com>
Date: Fri, 4 Mar 2011 20:42:29 -0500

Hi all,

I'm not sure where to ask this anymore, so here it goes. I've written a small RESTful service that's part of a prototype for GF 3.2 work. I have my @GET and @PUT methods working fine along with client code to call the service. But now I'm running into trouble with my @DELETE method.

This works:

    // server side
    @DELETE
    @Consumes(MediaType.TEXT_XML)
    public void deleteMaster() {}

    // client side
    webResource.type(MediaType.TEXT_XML).delete();

But what I want to do is pass an entity into the call so that the server can see if it actually matches the resource or not (and only delete it if it's the right one):

    // server side.
    // MemberInfo is a POJO annotated with @XmlRootElement that works fine in GET and PUT methods
    @DELETE
    @Consumes(MediaType.TEXT_XML)
    public void deleteMaster(MemberInfo memberInfo) {}

    // client
    webResource.type(MediaType.TEXT_XML).delete(memberInfo);

In this case, my @DELETE-annotated method is never called, and the client gets this exception:
HTTP method DELETE doesn't support output

I know how to work around this (I think) with the com.sun.jersey.api.container.filter.PostReplaceFilter class in Jersey and X-HTTP-Method-Override, but my question is "should I have to?" (or "am I doing this right?"). After wrestling with this service, the error message seemed ambiguous (my server method has no output), but I know it's the output stream of the HttpUrlConnection. So it looks like DELETE calls can carry no payload. Since I want to have a payload (*), should I simply make this a POST request?

I ask because I've seen people get really worked up about what is and isn't RESTful. If I'm doing this and others are going to see it, I should do it correctly.

Thanks,
Bobby

(*) There could be cases where several clients call this at the same time, each with a different idea of what is actually being removed. So the server needs to handle this in an atomic check-then-act fashion.