Hi Craig,
I think allowing query parameters is a good idea.
Note that you can do this:
service.uri(UriBuilder.fromPath("foo").queryParam("bar",
"baz").build()).get(...)
which will replace any existing query parameters on the WebResource.
But i agree it is rather horrible, probably as much as getting slapped
in the face with a fish, if you just want to set query parameters.
IIRC we have discussed this before. One approach was to emulate many
of the UriBuilder methods so one could do:
service.uri().path("foo").queryParam("bar", "baz").build().get(...)
But the MultivaluedMap<String,String>) you propose is much simpler.
I have *a lot* of preparation work ahead of me for many presentations
over the next 2 weeks so the simpler the better.
If i don't get this and the "*/*+json" and "*/*+xml" implemented today
it is unlikely i will get the time before the 1.0.1 release. I am
happy to defer over to yourself if you want to have a go.
Paul.
On Nov 27, 2008, at 8:04 AM, Craig McClanahan wrote:
> I've been working on client-side tests for a RESTful server API in
> my day job, and ran into an interesting scenario. Some of my
> service APIs support request parameters for filtering and sorting
> the returned results. But there doesn't seem to be any mechanism to
> allow a Jersey Client request to include such parameters. In
> particular, if you try something like this (in Jersey 1.0):
>
> service = ...; // WebResource for our service
> ClientResponse response = service.path("foo?
> bar=baz").get(ClientResponse.class);
>
> you will most likely get a 404 response back from your server.
> AFAICT, this is because the path() method is URL encoding its
> argument, so the "?" gets encoded instead of delimiting the request
> parameters. Yuck.
>
> In addition to everything else, I've been building Ruby and Python
> client SDKs for these web services, in addition to Java ones which
> are based on Jersey Client. I liked the Jersey Client builder
> pattern APIs so much that I pretty much emulated them in the other
> languages ... but I found the need to add an additional method to
> take query parameters and do the right thing.
>
> For Jersey Client, I would propose to fix this scenario along the
> same lines, by adding the following method signature to WebResource:
>
> public WebResource params(MultivaluedMap<String,String>);
>
> that would let you specify an appropriate map of request parameters,
> and return the WebResource instance (in builder pattern fashion) to
> continue the process of constructing the current request.
>
> What do you think? If we like it, I'd like to get this (in addition
> to the changes earlier discussed for "*/*+json" media types) into
> the 1.0.1 stream for release next week.
>
> Or, if there is a way to deal with request params in the current
> client apis, feel free to slap me with a fish :-).
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>