Hi,
Generally i would discourage from using instances of resource classes
as entities themselves as it means one can evolve the two
independently. But sometimes i can see why it can be convenient.
You might be able to encapsulate the container/item relationship as
generic classes you can extend from. You can reduce the List->Item by
two to one class with sub-resource methods for access to an item as
long as an item does not have further paths.
I think the approach we should take to improve this is to provide some
helper classes that one can extend and/or improve tooling w.r.t.
helping the developer with support for this pattern.
In general for JAX-RS we have tried to avoid locking the developer
into certain patterns, so it is more flexible, but does result in a
lack of guidance on what the best practices might be for common
patterns.
W.r.t the bookstore sample one could modify getTracks to be:
@GET
@Path("tracks")
@Produces({MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON})
public Track[] getTracks() {
return tracks;
}
Paul.
On Jul 14, 2010, at 6:13 PM, Basmajian, Raffi wrote:
>
>
> We are still struggling with Jersey and resource routing. We are
> able to
> access top-level resources with REST-ful requests, but when it comes
> to
> nested, 1-to-many object relationships (List<Class>), we can't get the
> routes to work unless we create a "<Class>Resources" and
> "<Class>Resource" implementation for each entity type. Seems like a
> lot
> of work for a framework that was meant to simplify.
>
> What approach are you guys taking? Do you try to minimize the number
> of
> resource classes regardless of the actual number of resources, such as
> in the Bookstore example, or, are you taking the opposite approach,
> such
> as in the Storage-Service example, where for each entity there is a
> Resources/Resource component? We like the Bookstore example with
> respect
> to CD-->Tracks where it uses the @Path("tracks") annotation in the
> Book
> class for accessing the tracks of the CD, but we can't get this to
> work
> with JAXB and xml instead of the JSP's in the sample.
>
> ------------------------------------------------------------------------------
> This e-mail transmission may contain information that is
> proprietary, privileged and/or confidential and is intended
> exclusively for the person(s) to whom it is addressed. Any use,
> copying, retention or disclosure by any person other than the
> intended recipient or the intended recipient's designees is strictly
> prohibited. If you are not the intended recipient or their designee,
> please notify the sender immediately by return e-mail and delete all
> copies. OppenheimerFunds may, at its sole discretion, monitor,
> review, retain and/or disclose the content of all email
> communications.
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>