On 16/10/12 14:06, Bill Burke wrote:
> Wouldn't changing resolveTempalte() and build() methods to state that
> '/' is not encoded and you must encode it manually work just as well? Or
> is it a backward compatibility issue?
>
> We have to provide a way for people to specify path params without
> encoding the '/', but it just seems silly to have a special method for
> this case.
>
Agreed the current solution is not ideal at all. Probably too late
though to revert. The real concern is, with "/" now getting a prominent
attention at the API level, what would happen if some other character in
say the query component will need another special treatment during the
substitution.
Sergey