On Jan 10, 2008, at 2:01 PM, Jose Antonio Illescas del Olmo wrote:
> 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
>
You could do something like this:
@Path("songs")
public class SongsResource {
public SongsResource(@QueryParam("groups_id") int groupId) {...}
@GET
public SongList getSongs() {...}
}
@Path("groups/{groupId}")
public class GroupResource {
...
@Path("songs")
public SongsResource getSongsResource(@PathParam("groupId") int
groupId) {
return new SongsResource(groupId);
}
}
Marc.
>
> 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_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.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net For
> additional commands, e-mail: users-help_at_jersey.dev.java.net
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.