Marc Hadley wrote:
> If you're resources are such that you can use a URI template to identify
> them then that is definitely the way to go rather than using
> sub-resources. Sub-resources are there to handle cases where the URI
> path is somewhat dynamic or when the same resource can be found at
> multiple paths (though you can always create a subclass for each and
> then still use a template).
>
It general it can also be used to model application objects to the URL
hierarchy, especially for the case when there are interconnected
relationships between the application objects (that can often be the
case when building complex Web applications e.g. how to support
breadcrumbs?).
The idea was taken from Hudson [1]. Specifically the underlying library
stapler [2] was used as a use-case. I like Hudson a lot :-) and one goal
i have to make it easy to build Hudson-like Web applications using Jersey.
The nice thing is you can start with a simpler style of having one or
more root resources then if there starts to be varying interconnecting
relationships you can easily move to the style of sub-resource locators.
I think we need to support (in addition to returning of Object) the case
of a sub-resource locater returning a Class so that the runtime can
instantiate the Object, and a mechanism to get access to resource
instances up in the URL hierarchy.
Paul.
[1]
http://hudson.dev.java.net
[2]
https://stapler.dev.java.net/what-is.html
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109