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
>
>