On Jul 2, 2008, at 4:14 AM, Stephan Koops wrote:
> Hi James,
>> In my 2nd 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.
Its already pretty explicit in the javadoc:
https://jsr311.dev.java.net/nonav/javadoc/javax/ws/rs/
Path.html#limited()
Marc.
>
>> 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/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
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.