I'm a bit late to this thread, if you really want to return different
types based on the mime type, would you not use
"application/json+iphone", etc and maintain the json link.
Secondly in these situations, I prefer to leave the annotations to a
minimum and handle the logic in the code, I find it makes the things
cleaner without having multiple duplicated functions, for example:
@GET
@PATH("/device/{id}")
public Object getDevice(@PathParam("id") Integer id){
// lookup device based on headers and query params, throwing a custom
exception if not valid
return deviceLookup(id);
}
But I imagine that is a whole separate thread topic :)
John
On 19:59, Cameron Heavon-Jones wrote:
> Hey Gili,
>
> Aren't you consuming\returning JSON?
>
> Why do you want to introduced new media types? (For reasons other than dispatch!)
>
> cam
>
> On 20/06/2011, at 3:43 PM, Gili wrote:
>
>> Hi Cameron,
>>
>> Here is my specific use-case:
>>
>> 1. I am using JSON, so @GET on /devices should return:
>>
>> [
>> “name”: string,
>> “type”: string,
>> “uri”: URI
>> ]
>>
>> Where "name" is a user-assigned identifier. "type" is the device
>> type/differentiator. I'm defining a hierarchy where all devices share the
>> same id sequence. See
>> http://en.wikibooks.org/wiki/Java_Persistence/Inheritance#Joined.2C_Multiple_Table_Inheritance
>> for an example.
>>
>> 2. Say /devices/5 refers to Device "A" but the user invokes @GET on
>> /devices/5 with Accepts "B", the resource should return HTTP 404 because
>> Device "A" with id 5 does not exist.
>>
>> 3. @GET on /devices/5 with the right Accepts header should return the
>> device's state
>>
>> 4. Now that I think about it, I don't want to have to declare @Consumes,
>> @Produces twice (once on the parent resource, and one on the actual
>> resource). Ideally I just want to provide Jersey with a list of possible
>> sub-resources and it should select the correct one by matching the user's
>> Accepts header to a sub-resource @Consumes/_at_Produces.
>>
>> Gili
>>
>>
>> Cameron Heavon-Jones wrote:
>>> When you say "Content-Type" i think of the http header, which is the
>>> MIME\Media type, but it seems you require alternate JAXB classes?
>>>
>>> Do the sub-resources provide any additional functionality or are you just
>>> looking for a way to return specific JAXB types?
>>>
>>> If you don't need additional functions on the resources, i think you could
>>> just return the correct type from the parent resource and let JAXB create
>>> the full xml based on specific type and data.
>>>
>>> However, if the sub-resources are distinct resources with specific
>>> operations you want them to have their own resource classes which seems to
>>> be the case form you example.
>>>
>>> In that case it comes down to resource design, specifically, is there a
>>> common ancestor which is required? Cat and Dog would suggest Animal as the
>>> common ancestor. But if your system is not some creature taxonomy where
>>> there is value in a hierarchy, but really a more real world case, you
>>> might not require the additional complexity this brings.
>>>
>>> I don't really think you can go wrong, both are equally valid, it comes
>>> down to a question of design, which is more constrained by your specific
>>> case.
>>>
>>> To go back to the "devices", if the client is aware of multiple types of
>>> devices i would be inclined to expose that information (barring business
>>> cases), however if the client is not aware of, does not care, or if the
>>> sub-resources are an implementation detail, i would not expose the
>>> information through structure.
>>>
>>> helpful? :)
>>>
>>> if you want to discuss a specific business case, feel free to email
>>> specifics privately and i will respect your business's and individual
>>> confidentiality if public dissemination is not desired.
>>>
>>> cam
>>>
>>>
>>> On 20/06/2011, at 1:24 PM, Gili wrote:
>>>
>>>> Hi Cameron,
>>>>
>>>> I would like to differentiate between the different devices based on
>>>> the Content-Type but the following code seems a bit weird:
>>>>
>>>> @Consumes("Dog")
>>>> @Produces("Dog")
>>>> public DogResource getDog()
>>>> {
>>>> return new DogResource();
>>>> }
>>>>
>>>> @Consumes("Cat")
>>>> @Produces("Cat")
>>>> public CatResource getCat(){
>>>> return new CatResource();
>>>> }
>>>>
>>>> [...]
>>>>
>>>> DogResource
>>>> {
>>>> @GET
>>>> public String getDog() {}
>>>> @PUT
>>>> public void setDog(String) {}
>>>> }
>>>>
>>>> CatResource
>>>> {
>>>> @GET
>>>> public String getCat() {}
>>>> @PUT
>>>> public void setCat(String) {}
>>>> }
>>>>
>>>> What do you think?
>>>>
>>>> Gili
>>>>
>>>> On 20/06/2011 8:04 AM, Cameron Heavon-Jones [via Jersey] wrote:
>>>>> it sounds like you want a differentiator to be able to choose between
>>>>> the types of resources.
>>>>>
>>>>> you will either require the client to provide the differentiator as part
>>>>> of their request - uri, media type, headers etc - the switch can be
>>>>> handled by jersey using annotations.
>>>>>
>>>>> or you can store locally in your database and lookup the correct type on
>>>>> request. in your case this would amount to loading the device from the
>>>>> database and checking it's differentiator:
>>>>>
>>>>> @Path("device/{id}")
>>>>> public DeviceResource getDevice(@PathParam("id") Long id){
>>>>> Device d =oadDevice(id);
>>>>> if (d.isSomeType()) // or instanceof with cast
>>>>> return new SpecificDeviceResource(device);
>>>>> else
>>>>> return new GenericDeviceResource(device);
>>>>> }
>>>>>
>>>>>
>>>>> The other method, to get this managed by the client instead, you could
>>>>> do:
>>>>>
>>>>> @Path("genericdevice/{id}")
>>>>> public DeviceResource getGeneric(@PathParam("id") Long id){
>>>>> return new GenericDeviceResource(id);
>>>>> }
>>>>>
>>>>> @Path("specificdevice/{id}")
>>>>> public DeviceResource getSpecific(@PathParam("id") Long id){
>>>>> return new SpecificDeviceResource(id);
>>>>> }
>>>>>
>>>>> or use some other request parameter other than the path.
>>>>>
>>>>> hth,
>>>>> cam
>>>>>
>>>>> On 17/06/2011, at 3:23 PM, Gili wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Currently when I want to specify sub-resource I do:
>>>>>>
>>>>>> @Path("devices")
>>>>>> class Devices
>>>>>> {
>>>>>> [...]
>>>>>> @Path("{id}")
>>>>>> public getDevice(@PathParam("id") long id)
>>>>>> {
>>>>>> return new Device(id);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> Now I have two different kind of devices, both mapped under
>>>>> /devices/{id}
>>>>>> except that some IDs are mapped to one device type and some to
>>>>> another. Is
>>>>>> it possible to specify two sub-resource methods and have Jersey
>>>>> instantiate
>>>>>> a different sub-resource Class depending on the content-type being
>>>>>> requested?
>>>>>>
>>>>>> Thanks,
>>>>>> Gili
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>> http://jersey.576304.n2.nabble.com/Specifying-different-sub-resources-depending-on-the-Content-Type-tp6487299p6487299.html
>>>>>> Sent from the Jersey mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> If you reply to this email, your message will be added to the discussion
>>>>> below:
>>>>> http://jersey.576304.n2.nabble.com/Specifying-different-sub-resources-depending-on-the-Content-Type-tp6487299p6495488.html
>>>>> To unsubscribe from Specifying different sub-resources depending on the
>>>>> Content-Type?, click here.
>>>>
>>>> View this message in context: Re: Specifying different sub-resources
>>>> depending on the Content-Type?
>>>> Sent from the Jersey mailing list archive at Nabble.com.
>>
>> --
>> View this message in context: http://jersey.576304.n2.nabble.com/Specifying-different-sub-resources-depending-on-the-Content-Type-tp6487299p6496030.html
>> Sent from the Jersey mailing list archive at Nabble.com.
--
www.pricegoblin.co.uk