Hi James,
> In my 2^nd example, regardless of extension mapping or content
> negotiation, I suspect the code would like to have different methods
> to find methods and dependencies.
>
> @Path(“java”)
> class CodeResource {
>
> @GET
> @Path(“{class}/methods”, limited=false)
> public List<String> getMethods(@PathParam(“class”) String cls) { … }
>
> @GET
> @Path(“{class}/dependencies”, limited=false)
> public List<Class> getDependencies(@PathParam(“class”) String cls) { … }
> }
>
> I believe the @Path values on these methods are invalid in the current
> spec.
> Changing the 3 @Path annotations to “java/{class}/”, “methods”, and
> “dependencies” will not work either as the unlimited {class}
> placeholder will consume the whole URI, leaving nothing to match the
> method @Paths.
you are right, the current javadoc says nothing what should happen with
@Path(value="{abc}/def", limited=false). If I remeber right, the limited
is only checked for trailing variables, so it is ignored in this
example. Marc, perhaps you could defines explicit, that the limited
attribute is ignored for all not trailing template variables.
> Swapping the order of the class and method/dependencies does NOT
> improve these URIs (in my opinion).
> _http://example.net/java/java/lang/Integer/methods.json_
> _http://example.net/java/javax/ws/rs/core/Request/methods.xml_
> _http://example.net/java/javax/ws/rs/core/Request/dependencies.xml_
> vs
> _http://example.net/java/__methods/__java/lang/Integer.json_
> <http://example.net/java/methods/java/lang/Integer.json>
> _http://example.net/java/__methods/__javax/ws/rs/core/Request.xml_
> <http://example.net/java/methods/javax/ws/rs/core/Request.xml>
>
> _http://example.net/java/__dependencies/__javax/ws/rs/core/Request.xml_
> <http://example.net/java/dependencies/javax/ws/rs/core/Request.xml>
> The first style of URI feels important enough for JAX-RS to support,
> but I don’t have hard evidence.
I agree, the first 3 URIs are better and more resource oriented.
best regards
Stephan