None, as fair as I am aware of. I've struggled with this problem in
the past as well, and came to the conclusion that JAXB ties the view
(resource) too rigidly with the model (POJO), making it impossible to
reuse POJO's elsewhere - basically it's a cute idea, but it just
doesn't scale in practice.
So we ended up using raw Jackson, which also has the added benefit
that you can start streaming results back immediately. The downside is
that it's still laborious to construct these slightly different
variations, so we've taken the next step into developing an OData
endpoint on top of Jersey, which allows the URL to specify the desired
projection, translate this into SQL (via a model) and feed back via
JSON. I'm no longer directly associated with this latter part, but I
believe the plan is to release this as open source for others to use.
/Casper
On Sun, May 27, 2012 at 5:24 PM, Rick Mangi <rick_at_broadcastr.com> wrote:
> I guess my question is more, what facilities (if any) does jersey provide
> for allowing for multiple json serialization formats for a single pojo?
>
>
>
> On Sun, May 27, 2012 at 8:54 AM, Rick Mangi <rick_at_broadcastr.com> wrote:
>>
>> I'd rather not pass extra parameters in. Ideally each service endpoint
>> would be able to have a different serialization of the domain models.
>>
>> Sent from my iPad
>>
>> On May 27, 2012, at 1:28 AM, Arul Dhesiaseelan <aruld_at_acm.org> wrote:
>>
>> Google Drive API does something similar by passing in an optional
>> parameter in the request that hints what response data is expected by the
>> target client.
>>
>> https://developers.google.com/drive/v1/reference/files/get
>>
>> Does this work for you?
>>
>> -Arul
>>
>> On Sat, May 26, 2012 at 8:26 AM, <rick_at_broadcastr.com> wrote:
>>>
>>> Hi, I asked this question on stackoverflow, but thought I would send it
>>> here as well..
>>>
>>> We have a set of domain classes which are serialized to json via
>>> jackson using jersey services. We are currently annotating the classes
>>> with JAXB (although we're not tied to that). This works fine. But we
>>> want to offer different serializations of the classes for different use
>>> cases.
>>>
>>> Web site
>>> Mobile apps
>>> Admin tool
>>> Public API
>>>
>>> In each of these use cases there are different fields which we may or
>>> may not want included in the json view. For example, the admin tool
>>> might need some parameters for setting permissions on data. The mobile
>>> client needs a different URL to a media stream than the website. The
>>> website has particular naming conventions it needs for fields.
>>>
>>> What is the best practice for managing different mappings of json for
>>> different service endpoints in Jersey?
>>>
>>> Thanks!
>>
>>
>>
>>
>> --
>> http://aruld.info
>> http://twitter.com/aruld
>>
>>
>