I managed to get both features completed and committed in the trunk.
Paul.
On Nov 27, 2008, at 1:30 PM, Paul Sandoz wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>