Hi,
I have added your suggestion to:
https://jersey.dev.java.net/issues/show_bug.cgi?id=183
Another solution i was thinking about was to provider a multipart
builder.
MultipartBuilder.param("a", "b").build();
but i think the pairs of String is better.
Paul.
On Jan 27, 2009, at 12:12 AM, jstrachan wrote:
>
> Just a thought - how about an extra helper method to avoid having to
> create a
> separate multi-map variable using java 5's varargs support.
>
> E.g.
>
> params(String... params) {...}
>
> Then folks could invoke it as
>
> resource.params("foo", foo, "bar", bar)...
>
> The implementation could just turn the String[] into the multi map.
>
> No biggie - it just seems adding one or two string based parameters
> is quite
> common
>
>
>
> Paul Sandoz wrote:
>>
>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>>
>
> --
> View this message in context: http://n2.nabble.com/Request-parameters-in-a-Jersey-Client-Request-tp1584265p2221340.html
> Sent from the Jersey mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>