And how to map this Resource: Songs of a (musical) Group (without any
other prefix as /music/songs or /music/groups)
/songs?groups_id=9
/groups/9/songs
Both URIs maps to same resource and return equal result
Jose
Marc Hadley wrote:
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@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@bt.com
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@jersey.dev.java.net
For additional commands, e-mail: users-help@jersey.dev.java.net