Paul Sandoz wrote:
> I managed to get both features completed and committed in the trunk.
>
Thanks Paul ... that's awesome! I'll check them out and play a bit to
ensure they do what I need in the next couple of days.
> Paul.
Craig
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>