Here is my suggestion. It probably makes sense to keep two separate
classes, even though UriBuilder can potentially
be used to create any possible URI. I think it is still useful to be
able to manipulate query parameters independent
of the URI that they are to be applied to, and I think the ability to
remove parameters and retrieve them individually
makes sense for query params (though not so much for other URI fields).
So, to that end, I propose:
1) We adopt UriBuilder with some methods removed (can be added back in
sub-class defined in javax.ws.rs)
but with a build() method added that takes a UrlEncodedQueryString
2) We remove the apply() methods from UrlEncodedQueryString because you
build URIs now through UriBuilder.
3) Most methods in UrlEncodedQueryString need to be renamed. The word
Parameter needs to be removed from all
of them. So, appendParameter() becomes append(). I think
appendParameters() should also be named append().
4) The parse() and create() methods should have the same name, and
possibly be aligned with the creation methods
in UriBuilder
5) I'm having second thoughts about exposing the Map outside of the
class. I'd like to look at the reason why
we did this again.
6) I think the separator char should be specified at object creation
time. I can't see any great benefit to it being
specified at the time apply() was called (though I know there may be
some cases we still need to support, where
different separators are used in the same query string).
Regards,
Michael
