I thought you wanted to submit a "body" to the GET? If it's just a single parameter, I don't see why you couldn't use GET. I could be wrong, but my understanding is that @GET should return the same results every time save any changes that occur from another call (like if someone else did a PUT/POST that updated the DB and affected the result set your GET call returned). But, you could pass in a different parameter every call, say to change the start index/end index of a large result set, or sort the response every time in a different way. Those would be query parameters and you'd simply use the @QueryParam() in your method signature for the @GET.
----- Original Message ----
From: "Lee, Deirdre" <Deirdre.Lee_at_deri.org>
To: users_at_jersey.dev.java.net
Sent: Friday, September 5, 2008 7:31:23 AM
Subject: RE: [Jersey] @GET @ConsumeMime - converter parameter
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