Hello,
*UriBuilder*
for the UriBuilder I think it should be possible to call the "setter"
methods with a given encode state, independent of the current instance
variable state, e.g. in a utility method. There are two solutions in my
mind:
* add for every method (host(.), port(.), query(.), ...) another
method with an additional boolean parameter encode, where the
application developer can set this property independant of the
internal encode state of the UriBuilder or
* add a method getEncode() to the UriBuilder, so you can request the
current encode state, set a new one and later switch back to the
old one.
Another point for the UriBuilder: IMO it should be more precised what
should be encoded in some methods in the javadoc (or whereever)
* in replacePath(String) the slash must not be encoded, of
course.What about ";" and "="? It could happe, that someone sets
some matrix parameters here. If this is not allowed, it should be
documented in the javadoc.
* in replaceQueryParams "=" and "?" must not be encoded.
* in replaceMatrixParams ";" and "=" must not be encoded.
* userInfo: should the ":" be encoded, for a setting of
"username:password". Perhaps we can change the signature to
userInfo(String ...). The array args could internally separated by
a ":" (see
http://tools.ietf.org/html/rfc3986#section-3.2.1). This
(String ...) is perhaps useful for all replace*() methods.
The encode specialities should be clarified in the javadoc, IMO. I
suggest also to allow null as parameter in this methods for clear the
path respectively the query parameters or the matrix parameters. It
could be also documented in the javadoc that the parameter "" will clear
the path and so on.
*MultivaluedMap of query / matrix parameters*
I think it should be documented if the MultivaluedMap should be
modifiable or not for the query parameteres and for the matrix
parameters. Unmodifiable is the right think in theory, but sometimes it
is useful to allow the modification.
*ResponseBuilder.tag(String)*
The javadoc of method ResponseBuilder.tag(String) says that this method
is used to set a strong entity tag. It is not documented what should
happens, if a weak tag is set. Should it be rejected with an
IllegalArgumentException or should it be allowed as a strong entityTag?
*Request.evaluatePreconditions()
*RFC 2616, Section 10.3.5 requires, that the headers Content-Location,
Expires, Cache-Control and/or vary must be under some conditions. How it
s possible with the current spec? Perhaps the method should return a
ResponseBuilder instead of a Response. So the application developer can
add it.
best regards
Stephan Koops