users@jersey.java.net

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

From: Jose Antonio Illescas del Olmo <jantonio.illescas_at_rbcdexia-is.es>
Date: Fri, 11 Jan 2008 16:58:02 +0100

Thank you, Marc your response is (very) concise and useful


Marc Hadley wrote:
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>