Use "application/vnd.nl.imc.ids+xml" or something, rather than
"application/ids"
On Fri, Apr 2, 2010 at 3:23 PM, Marc Hadley <marc.hadley_at_oracle.com> wrote:
> On Apr 2, 2010, at 4:43 AM, Paul Sandoz wrote:
> >>>
> >>> Thanks for the feedback. Storing the link as value is interesting since
> I mainly want to use this for optimization situations where a client wants
> to know about a large set ids but only a small set of them will ever need to
> be fully loaded on the client-side.
> >>>
> >>> Do you have any clue how I can extend the existing readers and writers
> so that I do not have to re-write my own? I have peaked inside the jersey
> library and there are so many providers I am not sure which I should extend.
> >>>
> >> Presumably you want to re-use the std JAXB reader/writer for the
> application/ids media type ?
> >>
> >> The easiest way to do it is to write your own (mostly empty)
> reader/writer for the application/ids media type and use the Providers
> interface:
> >>
> >>
> https://jsr311.dev.java.net/nonav/releases/1.0/javax/ws/rs/ext/Providers.html
> >>
> >> to look up the std reader/writer using "application/xml" for the media
> type. You can then defer to the std reader/writer from your reader/writer.
> >>
> >
> > Not sure if i am missing something or not, but If one can use different
> resource methods annotated with different @Produces (as you presented below)
> then why not just use different JAXB classes? and then there is no need to
> develop specific or wrapping message body writers.
> >
> The JAX-RS spec only requires support for JAXB classes using the following
> media types: text/xml, application/xml and application/*+xml. So if you want
> to use some other media type (portably at least) then you'd need a wrapper
> msg body writer.
>
> Marc.
>
> >>
> >>>
> >>> -----Original Message-----
> >>> From: Marc Hadley [mailto:marc.hadley_at_oracle.com]
> >>> Sent: Thursday, April 01, 2010 4:46 PM
> >>> To: users_at_jersey.dev.java.net
> >>> Subject: Re: [Jersey] 2 different xml representation for the same data
> >>>
> >>> What you have so far looks fine to me - no media-type abuse detected.
> >>>
> >>> You might consider adding links to the representations (e.g. each order
> could include a link to resource for that order) so clients don't have to
> construct them.
> >>>
> >>> Marc.
> >>>
> >>> On Apr 1, 2010, at 8:55 AM, Florian Hehlen wrote:
> >>>
> >>>> I have this interesting use case....
> >>>>
> >>>>
> >>>> I would like to be able to retrieve a list of objects or alternatively
> just a list of id's. I am thinking that this is just a different
> representation of the same data so I would like to use the same url with
> different media types.
> >>>>
> >>>> So it looks a like this...
> >>>>
> >>>> Request 1:
> >>>> curl http://store/orders/query?state=back-ordered
> >>>>
> >>>> reply 1:
> >>>> <orders>
> >>>> <order>
> >>>> <id>1</id>
> >>>> <state>back-ordered</state>
> >>>> /* plus all other properties */
> >>>> </order>
> >>>> <order>
> >>>> <id>2</id>
> >>>> <state>back-ordered</state>
> >>>> /* plus all other properties */
> >>>> </order>
> >>>> </orders>
> >>>>
> >>>> Request 2:
> >>>> curl -s -H Accept:application/ids
> http://store/orders/query?state=back-ordered
> >>>>
> >>>> reply 2:
> >>>> <pairs>
> >>>> <pair key="1" value="order" />
> >>>> <pair key="2" value="order" />
> >>>> </pairs>
> >>>>
> >>>>
> >>>> Has anyone else been down this path? It feels quite elegant to want to
> do it this way. I have written my own MessageBodyWriter and it works fine.
> But since both representations are xml I was hoping to be able to re-use
> existing jersey providers so I do not have to write my own
> serialization/deserialization code.
> >>>>
> >>>> At the end of the day I just want to re-direct the calls to different
> methods in my resource
> >>>>
> >>>> @Path("orders/query")
> >>>> Public class Resource {
> >>>>
> >>>> @GET
> >>>> @Produces({"application/xml"})
> >>>> Public Order[] findByState(@QueryParam("state")String state) {
> >>>> //...
> >>>> }
> >>>>
> >>>> @GET
> >>>> @Produces({"application/ids"})
> >>>> Public Pair[] findByStateAsId(@QueryParam("state")String state) {
> >>>> //...
> >>>> }
> >>>> }
> >>>>
> >>>> Am I barking up the wrong tree? Am I abusing media-types?
> >>>>
> >>>> Cheers,
> >>>> Flo.
> >>>>
> >>>> The information in this e-mail is intended only for the person or
> entity to which it is addressed.
> >>>>
> >>>> It may contain confidential and /or privileged material. If someone
> other than the intended recipient should receive this e-mail, he / she shall
> not be entitled to read, disseminate, disclose or duplicate it.
> >>>>
> >>>> If you receive this e-mail unintentionally, please inform us
> immediately by "reply" and then delete it from your system. Although this
> information has been compiled with great care, neither IMC Financial Markets
> & Asset Management nor any of its related entities shall accept any
> responsibility for any errors, omissions or other inaccuracies in this
> information or for the consequences thereof, nor shall it be bound in any
> way by the contents of this e-mail or its attachments. In the event of
> incomplete or incorrect transmission, please return the e-mail to the sender
> and permanently delete this message and any attachments.
> >>>>
> >>>> Messages and attachments are scanned for all known viruses. Always
> scan attachments before opening them.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >>>
> >>>
> >>> The information in this e-mail is intended only for the person or
> entity to which it is addressed.
> >>>
> >>> It may contain confidential and /or privileged material. If someone
> other than the intended recipient should receive this e-mail, he / she shall
> not be entitled to read, disseminate, disclose or duplicate it.
> >>>
> >>> If you receive this e-mail unintentionally, please inform us
> immediately by "reply" and then delete it from your system. Although this
> information has been compiled with great care, neither IMC Financial Markets
> & Asset Management nor any of its related entities shall accept any
> responsibility for any errors, omissions or other inaccuracies in this
> information or for the consequences thereof, nor shall it be bound in any
> way by the contents of this e-mail or its attachments. In the event of
> incomplete or incorrect transmission, please return the e-mail to the sender
> and permanently delete this message and any attachments.
> >>>
> >>> Messages and attachments are scanned for all known viruses. Always scan
> attachments before opening them.
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>