users@jersey.java.net

Re: [Jersey] Multiple HTTP methods per resource method

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Fri, 14 Nov 2008 14:14:50 -0500

On Nov 14, 2008, at 12:35 PM, Jeremy Whitlock wrote:
> Is there a technical reason for not allowing multiple HTTP
> method annotations per single resource method?

Its more philosophical than technical. The semantics of HTTP methods
differ and servicing multiple HTTP methods via a single Java method
could lead to their conflation. The JAX-RS spec disallows multiple
method designators on a single Java method.

> For example, I'd like
> something like this:
>
> @POST
> @PUT
> @Path("/person/create.{format}")
> @Produces({"application/json", "application/xml"})
> @Consumes("application/x-www-form-urlencoded")
> public Response createPerson(@PathParam("format") String format, Form
> formData) {
> // Do work
> }
>
As a general rule of thumb try to avoid verbs in URIs (create in the
above) otherwise you can find yourself following an RPC-oriented design.

> The reason for this is that some web browsers do not allow the PUT
> method to be used, or haven't in the past. That being said, many
> service providers using REST end up having to support both PUT and
> POST
> for create operations.

A common pattern is to use POST to create resources when the server is
in charge of the URI space and PUT to create resources when the client
is in charge of the URI space (within reason). So, e.g., you could
POST /person to create a new person resource, the server assigns the
new resource an identifier and then returns a "see other" status with
the URI of the newly created resource in the Location header.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.