dev@jersey.java.net

Re: removal of _at_SubResource

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 12 Jul 2007 12:59:28 +0200

Nam Nguyen wrote:
>
> Another point is that sub-resource classes are forced to use @HttpMethod
> annotations, whereas top resource classes could just have the
> @HttpMethod implied by method name prefixes like "get".

It depends on what rule is specified to consistently identify HTTP
methods. The rule you suggested could be applied consistently in all
cases, but it would make things even more ambiguous.

Currently all HTTP methods are required to be annotated with @HttpMethod
[1] whether they be members of a root resource class or a resource class.


> This kind of
> inconsistence could be potential confusion for the API.
>
> IMHO, it would be much simpler if we have explicit resource declaration
> with marker annotation like
>
> @WebResource(uriTemplate="a")
> class MyResource {
>
> // sub-locator method
> @SubResource(uriTemplate="b")
> public MySubResource getMySubResource(...) {
> // Life-cycle is per-request
> return new MySubResource(...);
> }
> }
> }
>
> @WebResource
> class MySubResource {
> public MySubResource(...) { ... }
> }
> }
>
> This explicitness would be easier for both developers

I can see where you are getting at, and it would be consistent with
other mechansims (like JAXB, JAX-WS, JPA). Although the way i would go
about looking at a 311 application is to identify the root resources
then for each of them follow the sub-locators. IMHO it is important to
know what context a resource class is used in. The fact that a developer
may know that a class is a resource class is nice but is not sufficient
to really understanding that class as a resource class.

What could be useful as a tool is to provide some sort of graphical view
(showing URIs) of root resource classes and sub-locators, and so on. Of
course it is not always possible to traverse a sub-locator because
sometimes the object returned can only be know at runtime (but if it is
a base class then all inherited classes as options could be shown, plus
runtime imposing by a tool could actually build up a more accurate view).


> and tools.
>

Given that the rules are very clear w.r.t. annotations i don't think it
is that hard for tools:

   for (Method m : clazz.getMethods())
     if (m.isAnnotationPresent(HttpMethod.class) ||
         m.isAnnotationPresent(UriTemplate.class)) return true;
   return false;

Paul.

[1] https://jsr311.dev.java.net/releases/0.1/javax/ws/rs/HttpMethod.html

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109