users@jersey.java.net

Re: Multiple UriTemplate Annotations for Generic 'Handler' Classes?

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 10 Jan 2008 13:15:18 -0500

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.