Marc
many thanks for your concise response - I feel pretty comfortable that
there is a 'technical' capability to address my particular requirement.
As such I see how I can get the level of control I need but I'm
concerned about the potential implications for my 'clean' namespace. For
example if I have say 3 root resources in my public resource namespace
(those published to my clients as part of their interface contract), one
of which has a concrete representation and two of which have a
dynamically assembled representation as follows:
http://res.domain.com/atomic-res1 //served directly from an atomic
datasource via entity class
http://res.domain.com/virtual-res2 //assembled via back-end integration
http://res.domain.com/virtual-res3 //assembled via back-end integration
Then are you suggesting that I would need to inject a root 'branch' to
explicitly segregate the 'virtuals' in order to exploit the capability
you've outlined along the lines of:
/atomic-res1
/virtual/virtual-res2
/virtual/virtual-res3
...
Such that I would have something like this:
@Path("/atomic-res1") /
public class AtomicResource1 {
//standard O/R based represnetation production
}
@Path("/virtual")
public class VirtualResourceRouter {
@Path("{resource}")
public Object resolve(@PathParam("resource") String resource) {
if (resource.equals("virtual-res2")
return new VirtualResource2(...);
else
return new VirtualResource3(...);
}
}
So whilst I understand how this can work - I introduce
technology-induced padding into my resource namespace which I'm
attempting to keep clean and meaningful. This may seem like a small,
cosmetic observation but purity in the namespace is an area of great
sensitivity in our work to date.
Sitting back and thinking about this (for the sake of argument) I'm
thinking I 'could' technically push all my root resources via this
front-end router (rooter :-) but that's sort of working against the
benefits of the scheme. On the other hand, unless I've misinterpreted
you, my published namespace is gonna be impacted - where my ideal
scenario means I could add my two virtual root resources "/virtual-res2"
and "/virtual-res3" @Path annotations to the router class without
impacting my URI scheme.
Thanks
Stewart