On 20/06/2011 12:56 PM, Cameron Heavon-Jones [via Jersey] wrote:
> Hey Gili,
>
> Aren't you consuming\returning JSON?
>
> Why do you want to introduced new media types? (For reasons other than
> dispatch!)
Because of
http://stackoverflow.com/questions/972226/how-to-version-rest-uris/975394#975394
1. It helps with versioning resources.
2. The way I see it, the MimeType indicates the class name, the path
indicates the property. If you specify application/json across the board
then you can't differentiate between creating different kinds of
devices. For example:
@POST /devices
without custom mime types you have no way of knowing which kind of
device. For resources with a JSON body you could embed the resource type
into the @POST entity body but (in my opinion) it is much cleaner to
specify the resource type using MimeType and dedicate the entity body to
the actual value of the resource. Now, I can use @POST /devices to
create as many different kinds of devices as I want.
> So they really are different media types? The only problem is that
> this requires the explicit and exact use of current media types which
> is ok but a more flexible solution would probably just use specific
> uri path. then i can still get the correct response from a browser
> which sends text\html accept.
In my case, different devices have different properties. The only
property they share is "name". Beyond that, each subclass has different
properties.
> This can be enforced as you showed through created new methods with
> consume\produce annotations, but since there will always be a device
> with id=5, and no duplicate ids, i'm not sure what you're really
> accomplishing if this is just to return data?
Because each subclass contains different fields, I need to issue
different database queries to retrieve the data (remember, each subclass
is mapped to a different table).
>
> >
> > 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
> >
>
> How about this?
>
> @Consumes(IPHONE_TYPE)
> public IPhoneDevice getIphone(String id){
> return new IphoneDevice(id);
> }
>
> @Consumes(ANDROID_TYPE)
> public AndroidDevice getAndroid(String id){
> return new AndroidDevice(id);
> }
>
> Any @Consumes annotation on the sub-resource is not used, as this has
> already been restricted on the locator.
>
> I think i'd prefer using a path name but this would work ok.
Okay I assume this is no different from doing this:
@Consumes(ANDROID_TYPE)
public Response getAndroid(String id)
{
return new AndroidDevice(id).get();
}
The only benefit of sub-resources would be if I could funnel
multiple methods (GET, PUT, DELETE, etc) through a single method in the
parent resource. Assuming the child resource contains the following methods:
@GET
@Produces(ANDROID_TYPE)
@PUT
@Consumes(ANDROID_TYPE)
@DELETE
@Consumes(ANDROID_TYPE)
is there a way for me to funnel requests to it? If I declare:
@Consumes(ANDROID_TYPE)
@Produces(ANDROID_TYPE)
public AndroidDevice getAndroid(String id)
doesn't this imply adding a @Consumes to @GET and @Produces to @PUT
and @DELETE? That's not really what I'm going for.
Thanks,
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 = loadDevice(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.
>
>
>
> ------------------------------------------------------------------------
> 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-tp6487299p6496553.html
>
> To unsubscribe from Specifying different sub-resources depending on
> the Content-Type?, click here
> <http://jersey.576304.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6487299&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NjQ4NzI5OXwxNTc0MzIxMjQ3>.
>
--
View this message in context: http://jersey.576304.n2.nabble.com/Specifying-different-sub-resources-depending-on-the-Content-Type-tp6487299p6496793.html
Sent from the Jersey mailing list archive at Nabble.com.