> -----Original Message----- > From: Sergey Beryozkin [mailto:[email protected]] > Sent: Sunday, April 24, 2011 10:12 AM > To: [email protected] > Subject: Re: Need to get the format CXF agreed to > > Hi > > On Fri, Apr 22, 2011 at 11:02 PM, KARR, DAVID (ATTSI) <[email protected]> > wrote: > > In my REST service, I've come to the conclusion that while I'm > building the response, I'm going to need to know what decision CXF came > to in regards to output format. That is, XML vs. JSON. > > > > Previously, I didn't need to care, but I'm generating a HATEOAS URL > in the response, and we're considering whether this URL should be > unadorned, or whether it should explicitly specify the desired Accept > (and Accept-Language) value, by adding a file extension. This > definitely means the XML output won't be equivalent to the JSON output, > which bothers me at some level, but I don't know if I should care. > > > > In principle, CXF may let the application code know the final > Content-Type of the response, even before the suitable > MessageBodyWriter has been found, however you'd definitely have to > resort to using CXF specific API. > I may want to consider the following two options: > - Instead of using @Produces({"application/xml", "application/json"}) > and a single method, have two methods, one with > @Produces("application/xml"), the other - with > @Produces("application/json")
My @Produces is currently on the controller, which has perhaps 15 handler methods. If I'm understanding this suggestion correctly, you're suggesting I remove the controller-level @Produces, almost duplicate every single handler method, each with its own @Produces annotation, divided between json and xml. That doesn't seem reasonable. > - Use HttpHeaders.getAcceptableMediaTypes which has to return a sorted > list of acceptable media types, youcan check the list, if the 1st one > is xml-related then it's xml, etc This one looks reasonable. The URL building is done in a utility method that is called by every handler, so that can work.
