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