Hi Paul, Jason, All,
Paul Sandoz schrieb:
> On May 28, 2010, at 11:41 PM, Bill Shannon wrote:
>> I don't see how "{jndi/foo}" solves the original problem.
>> Doesn't that just look like two elements in the URL name -
>> "{jndi" and "foo}"?
In theory, you may be right, but in practice, JAX-RS stops interpreting
path fragments at the appropriate leaf level - see
https://jsr311.dev.java.net/nonav/releases/1.1/spec/spec3.html#x3-300003.4
so if you annotate for
.../management/domain/resources/admin-object-resource/{jndi/foo}
@Path("admin-object-resource/{name}")
public void someMethod(@PathParam("name") String name) { ... }
I would expect name to equal "{jndi/foo}" just as desired (but have to
admit I haven't (yet) tried it myself).
> And '{' and '}' are not legal characters in URIs so they would need to
> be percent encoded.
Not quite: '{' and '}' are just "unsafe" characters, which means they
"present the possibility of being misunderstood within URLs for various
reasons." There is only a soft requirement that such characters "should"
be encoded, but in my interpretation (and from past experience - but
with a plain HttpURLConnection client and a server evaluating URL
parameters "by hand"), you are not forced to do so.
As every other character which (IMHO) makes sense (including double
quotes) is also at least "unsafe" (if not strictly forbidden) for URLs,
one could only opt for an exclamation mark '!' - which would make it
look like
.../management/domain/resources/admin-object-resource/!jndi/foo!
but then again exclamation marks seem pretty ugly to me...
Conclusion: I myself would still opt for optional quoting of values by
delimiters such as '{' and '}' in order to avoid any potential
misunderstandings between values and resource paths.
All other options:
[1] .../management/domain/resources/admin-object-resource/jndi/foo
[2] .../management/domain/resources/admin-object-resource/jndi%2Ffoo
[3] .../management/domain/resources/admin-object-resource/jndi%252Ffoo
IMHO are either ambiguous like [1], both ambiguous and ugly like [2] or
non-ambiguous but extremely ugly (and hard-to-explain!) like [3]...
Just my 2 cents...
Best regards,
Andreas
--
Andreas Loew
Senior Java Architect
Sun Microsystems (Germany)