|
|
|
|
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!
|
|
|
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, <[hidden email]> 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.infohttp://twitter.com/aruld
|
|
|
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 < [hidden email]> 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, <[hidden email]> 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.infohttp://twitter.com/aruld
|
|
|
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 <[hidden email]> 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 < [hidden email]> 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, <[hidden email]> 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.infohttp://twitter.com/aruld
|
|
|
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 < [hidden email]> 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 < [hidden email]> 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 < [hidden email]> 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, < [hidden email]> 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>>
>>
>
|
|
|
Hmm... do you use jackson directly for unmarshalling posts/puts as well?
Thanks,
Rick On Sun, May 27, 2012 at 11:46 AM, Casper Bang <[hidden email]> wrote:
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 < [hidden email]> 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 < [hidden email]> 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 < [hidden email]> 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, < [hidden email]> 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
>>
>>
>
|
|
|
On Sun, May 27, 2012 at 8:46 AM, Casper Bang < [hidden email]> wrote:
> 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
...
One possible extension point is to have a look at the provider that is
used to integrate Jackson with JAX-RS. This is where one can add
things like annotation- or header/query-param-based routing and
dispatching. Or even use content/media-type for deciding how to handle
a request, and by whom.
The default implementation (JacksonJaxrsJsonProvider) is relatively
simple, which is mostly because it is not easy to figure out a generic
system that would allow useful toggles for things like asked here.
But it is not all that difficult to figure out how to handle specific
use case, in "locally generic" way. That is: logic for determining is
based on specific domain and use case, and custom annotations are
added to support just those cases.
I think all the flexibility & power of JAX-RS -- which handles LOTS of
use cases with very simple config and annotations -- sort of hides the
possibility of using custom extensions, which can solve further set of
use cases.
-+ Tatu +-
|
|
|
Thanks Tatu,
?
Thanks,
Rick On Mon, May 28, 2012 at 1:45 PM, Tatu Saloranta <[hidden email]> wrote:
On Sun, May 27, 2012 at 8:46 AM, Casper Bang < [hidden email]> wrote:
> 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
One possible extension point is to have a look at the provider that is
used to integrate Jackson with JAX-RS. This is where one can add
things like annotation- or header/query-param-based routing and
dispatching. Or even use content/media-type for deciding how to handle
a request, and by whom.
The default implementation (JacksonJaxrsJsonProvider) is relatively
simple, which is mostly because it is not easy to figure out a generic
system that would allow useful toggles for things like asked here.
But it is not all that difficult to figure out how to handle specific
use case, in "locally generic" way. That is: logic for determining is
based on specific domain and use case, and custom annotations are
added to support just those cases.
I think all the flexibility & power of JAX-RS -- which handles LOTS of
use cases with very simple config and annotations -- sort of hides the
possibility of using custom extensions, which can solve further set of
use cases.
-+ Tatu +-
|
|
|
This post has NOT been accepted by the mailing list yet.
If you learn more about replica watches, please visit www.solfwatches.com
|
|
|
This post has NOT been accepted by the mailing list yet.
Juliana Ribeiro and André Lima have known each other since their youth. The vice president of fashion and lifestyle at Black Frame PR and the neurologist first met through their families who just happened to be friends. “He and I were never really close,” the Brazilian-born Ribeiro explains. “But years later, we reconnected at my parents’ home during their New Year’s Eve party,” she adds. “That was when our relationship started, and we dated for two years before he proposed.” As fate would have it, the pair’s engagement, on Ribeiro’s 30th birthday, happened in the exact spot where they met. As she remembers, “my grandmother and mother knew what was about to happen because they helped design the ring, and our other family members and friends had a feeling it would happen on my birthday, especially after he showed up with a small box in his pocket. Turns out, the box was actually a pair of earrings for me, so I was a bit disappointed when I opened them. However, much later, around 2:00 a.m., we were dancing, and he whispered ‘Will you marry me?’ in my ear.”
long evening dresses
That was in November. In December, Ribeiro became pregnant and they began planning their wedding for May. “I never dreamed of a big wedding, nor did I have any specifics in mind,” Ribeiro notes. “But I did know that I wanted to get married in this church in Lisbon, where my parents have an apartment, at a monastery called Mosteiro dos Jerónimos. I first saw it when I was 15 and thought it was so beautiful.” As fate had it once again, Lima’s family is Portuguese, and their setting could not have been more perfect.
long prom dresses
The ceremony at the church was traditional, with a soloist singing classic wedding hymns alongside a children’s chorus. “It was such a special moment for me to see all my friends and family together in one place,” Ribeiro says. “The ceremony felt very intimate, even though the church was very grand and the outside was filled with tourists.” The bride wore a classic white satin gown with a long cape that was embroidered by her great aunt to include her mother’s old veil. Her hair was in a low bun, embellished with a vintage beaded headpiece, and she wore only her mother’s small pearl and diamond earrings and her wedding band.
wedding dresses online
Once the ceremony was over, the newlyweds and their guests headed to the reception at the nearby Palácio do Conde d’Óbidos. “I really love the Portuguese culture and aesthetic,” Ribeiro says. “This old palace on the river has the traditional blue-and-white tiles, and since the decor is already so amazing, I didn’t have to do much else to the space.” She did, however, have the napkins and tablecloths printed with the same motif as the tiles, and matched her orchids and hydrangeas to the white and blue hues. The reception actually began at 3:00 p.m. and went until 3:00 a.m., and when dinner was served sometime in between, guests were treated to classic Portuguese fare like veal, codfish baked with potatoes and eggs, and a native sweet called pastel de crema. During dinner, the bridesmaids presented a film they’d made that showcased the newlyweds as children and then their story as a happy couple. Later came what Ribeiro called, “the biggest surprise of the evening.” “André, my uncle, my cousin, and two friends did a fully choreographed dance that no one had a clue about,” she says. “My husband actually hired a professional to teach him a dance to a special remix of all the cheesiest Bruno Mars love songs, and for the guys who weren’t in Brazil with him at the time, he taped himself doing the dance to send to them so they could practice,” she adds. “He’s a neurologist and pretty serious most of the time, so this was incredibly funny.”
Though Lima’s performance certainly took the cake, the DJ had everyone from Ribeiro’s grandfather to her little cousins on the dance floor too. And at dusk, all of the guests gathered outside to release lit balloons into the sky for good luck. After, while the music raged on, something seemed to slip Ribeiro and Lima’s minds. “We were so excited to dance with all of our friends and family that we actually forgot to do the first dance,” Ribeiro remembers. “Our first dance was actually the last song of the evening, and it was a Caetano Veloso song that played on the radio during our first date—the perfect ending to a happy day.”
|
|
Locked
