users@jersey.java.net

RE: [Jersey] _at_GET _at_ConsumeMime - converter parameter

From: Lee, Deirdre <Deirdre.Lee_at_deri.org>
Date: Fri, 5 Sep 2008 15:31:23 +0100

Hi,

 

I didn't think of @POST or @PUT first, because I actually didn't want to edit the database; I just wanted to resubmit a value which I had previously retrieved via a @GET call, i.e. use the value as a parameter of another REST service. But looking back over things, I can use @PUT.

 

Thanks for the replies,

D

 

________________________________

From: Kevin Duffey [mailto:andjarnic_at_yahoo.com]
Sent: 05 September 2008 11:05
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] @GET @ConsumeMime - converter parameter

 

I actually like that Jersey throws an error on sending in body to GET, as well as DELETE. Why not just use POST or PUT instead as that is what they are intended for?

 

----- Original Message ----
From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
To: users_at_jersey.dev.java.net
Sent: Friday, September 5, 2008 2:44:13 AM
Subject: Re: [Jersey] @GET @ConsumeMime - converter parameter

Hi,

 

Do you want to break the meaning of HTTP GET to have unintended side effects from the perspective of the client? namely to change state e.g. update or delete information? if so you are breaking a very important REST constraint. In the particular example (which i am guessing is from NB generated code) the post method creates a new resource from the CustomerConverter instance, thus if that method was indeed annotated with @GET it would be breaking the semantics of HTTP GET.

 

If not, then mandating that the client is required to send entity information with the GET request reduces the effect of the uniform interface and passing URIs around e.g. if you give me a URI i can at least send OPTIONS/HEAD/GET requests to the resource the URI references with knowing much about that resource.

 

Strictly speaking a GET request does not disallow an entity body, i have not come across an example out there that uses it properly. Jersey restricts the method signature of @GET annotated methods because the likelihood is that a developer is doing something wrong if they want an entity in a GET request.

 

If developers want to use this RESTfully i could define a feature, with a default value of false, that can be enabled.

 

Paul.

 

On Sep 5, 2008, at 11:23 AM, Lee, Deirdre wrote:





Hi,

I¢m new to JAX-RS and have a question regarding @GET parameters. Looking at examples, I see this is the typical way to construct a resource class:

 

@Path("/customers/")

public class CustomersResource {

@Context

private UriInfo context;

 

@GET

@ProduceMime({"application/xml", "application/json"})

public CustomersConverter get(

@QueryParam("start") @DefaultValue("0") int start,

@QueryParam("max") @DefaultValue("10") int max) {

......

}

 

@POST

@ConsumeMime({"application/xml", "application/json"})

public Response post(CustomerConverter data) {

....

}

}

 

However, I was wondering if it was possible to do the following:

@GET

@ConsumeMime({"application/xml", "application/json"})

public Response post(CustomerConverter data) {

....

}

i.e. pass a converter class as a parameter to a GET function. I¢ve tried, but this has resulted in errors, so I was wondering if anyone could explain why this isn¢t possible.

 

Thanks,

D