Hi,
perhaps it would be an option to use xpath expressions (with includes
and excludes)? And perhaps this could be implemented as a filter.
Cheers,
Martin
On Thu, 2008-10-09 at 17:05 +0200, Paul Sandoz wrote:
> Hi Janne,
>
> You raise a very interesting point. Some type of query parameter to
> declare the nesting level could do it. Or perhaps default nesting
> levels s could be declared depending on the User-Agent.
>
> IMHO i think for this type of thing hypermedia is really important:
>
> <!-- a nesting of 3 -->
> <employees>
> <employee href="..."/>
> <id>123</id>
> <firstName>John</firstName>
> <lastName>Doe</lastName>
> <address href="..."/>
> <department href="..."/>
> </employee>
> <employee href="..."/>
> <id>234</id>
> ..
> </employee>
>
> This way limited clients could make more smaller requests. While less
> limited clients could make fewer larger requests but it all works
> consistently via the hypermedia.
>
> Currently this is harder to do that it should be. We need better
> integration support with JAXB for working with hypermedia and
> connecting it to resource classes.
>
> A simpler non-hypermedia type solution may be possible to limit the
> nesting if JAXB marshaling can be customized. For example a StAX
> wrapper could keep track of the hierarchy and not omit XML elements
> below a certain nesting level.
>
> Paul.
>
> On Oct 9, 2008, at 1:34 PM, Kytömäki, Janne wrote:
>
> > Hi,
> >
> > Since Victor got an answer for best practices for JAX-RS paging,
> > I'll give it a shot too with different problem. :-)
> >
> > Objects serialized and returned by JAX-RS services may be complex
> > and have lots of nested objects, thus an XML serialized list of just
> > a few objects can weight tens or hundreds of kb's. Some clients,
> > like a web AJAX application with large screen estate, may find all
> > of this data useful and have no problem with even large file
> > transfers, whereas other clients, such as a mobile application,
> > might prefer getting only a subset of data per object that it can
> > quickly (and cheaply) download and fit on its limited screen and
> > then get the details for a particular object when needed via a
> > subsequent JAX-RS request. It feels a bit cludgy to implement
> > separate JAX-RS services for example for the AJAX and the mobile
> > application, one that would return the full object trees and one
> > that would only return limited versions of the objects. Does anybody
> > have any ideas how one should make the object serialization
> > customizable by the client with JAX-RS while using the same service
> > and same source objects? Perhaps the client should define required
> > object properties in the request and these should be passed to the
> > JAXB binding process somehow in the service?
> >
> > Example:
> >
> > Let's say we have a JAX-RS service /employees/ that returns a list
> > of all employees for a company. An example of returned document in
> > XML format:
> >
> > <employees>
> > <employee>
> > <id>123</id>
> > <firstName>John</firstName>
> > <lastName>Doe</lastName>
> > <address>
> > <street>Abc 123</street>
> > <city>New York</city>
> > <zip>12345</<zip>
> > </address>
> > <department>
> > <id>123</id>
> > <name>Marketing</name>
> > <parentDepartment>
> > <id>234</id>
> > <name>Corporate Services</name>
> > <parentDepartment>
> > <id>345</id>
> > <name>Acme Ltd.</name>
> > </parentDepartment>
> > </parentDepartment>
> > <department>
> > </employee>
> > <employee>
> > <id>234</id>
> > ..
> > </employee>
> > ..
> > ..
> > ..
> > <employees>
> >
> > The example AJAX application client prefers this full object
> > serialization, but the limited mobile client would prefer only
> > getting the employee id's and names to populate a list, and when
> > required (i.e. user selects an employee on the list), it would then
> > call /employee/{id} to get the details for a particular employee:
> >
> > <employees>
> > <employee>
> > <id>123</id>
> > <firstName>John</firstName>
> > <lastName>Doe</lastName>
> > </employee>
> > <employee>
> > <id>234</id>
> > ..
> > </employee>
> > ..
> > ..
> > ..
> > <employees>
> >
> > Thanks,
> > Janne
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net