I suggest you look at using subresource locators, essentially these
are methods that dynamically match a resource path to the
corresponding object. E.g. say you have uris like:
/foo/bar
/foo/baz
/foo/buz
You can write a resource class to handle these like this:
@Path("foo") // note that @UriTemplate has been renamed in 0.5 to @Path
public class FooResource {
@Path("{resource}")
public Object resolve(@PathParam("resource") String resource) {
if (resource.equals("bar")
return new BarResource(...);
else
...
}
}
If needed you can use the limited property of @Path to support multi-
segment path parameters, e.g.
@Path(value="{resource}", limited=false)
will match:
/foo/bar => resource="bar"
/foo/bar/baz => resource="bar/baz"
/foo/bar/baz/buz => resource="bar/baz/buz"
Alternatively a returned resource class can have its own subresource
locators such that each subresource locator just consumes a single
path segment.
Hope that helps,
Marc.
On Jan 10, 2008, at 12:47 PM, stewart.welbourne_at_bt.com wrote:
> Hi
> I originally posted some thoughts (http://thestewscope.wordpress.com/2008/01/10/rubyrails-uri-patterns-and-jsr311/
> ) as I was getting up to speed on JSR311 and Jersey. It relates to a
> specific need I have to manage the formation of resource
> representations dynamically, where a single class/handler may
> underpin 2 or more discrete UriTemplates. In this case I was
> unclear how to pin a range of templates to a single generic class:
>
> //So this is the basic mechanism for exposing a simple data set
> through a single URI
> @UriTemplate("/concreteresource)
> Public class MyConcreteResource {
> //Relying on O/R mapping to an atomic datasource
> }
>
> But where the assembly of (lets call them virtual) resource
> representations relies on more complex back-end interactions I want
> to centralise the processing as follows:
>
> @UriTemplate("/virtualresourcetype1)
> @UriTemplate("/virtualresourcetype2)
> @UriTemplate("/virtualresourcetype3)
> Public class MyVirtualResourceHandler{
> //Here I do some meta-data driven back-end integration to
> resolve the representations
> }
>
> I'd appreciate views on whether JSR311/Jersey annotations support
> this kind of overloading, or alternatively what the optimal class
> arrangement would be if there's a pattern to support this.
>
> Thanks
> Stew
>
> Stewart Welbourne
> stewart.welbourne_at_bt.com
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.