I'm experimenting with defining my own media types (in the examples
below, "x-foo/x-bar" is used), to give clients of my JAX-RS service a
bit more information than generic content types like "application/json"
or "application/xml". But, I still want to support both XML and JSON
representation of the resources, because some clients (or the developers
of some clients :-) might prefer one format over the other.
A convention that I've seen in the wild is to add "+xml" or (by
extension) "+json" to the media type, to communicate both the actual
media type and the desired representation syntax together. Thus, I
might have a resource method like this:
@GET
@Produces{{"x-foo/x-bar+xml", "x-foo/x-bar+json"})
public Response getResults(...) { ... }
where the response entity is going to be a JAXBElement ... in theory,
that way, I get either XML or JSON serialization with no extra effort.
The problem I'm seeing, though, comes from doing a request that includes:
Accept: x-foo/x-bar+json
The response I get claims "x-foo/x-bar+json" as its Content-Type, but in
reality it's XML. Hmm.
Digging into the Jersey code a bit, it appears that the root cause of
this is that Jersey's JSONJAXBElementProvider class (the one that does
the JSON serialization for JAXB objects) declares that it consumes and
produces only "application/json", so naturally it doesn't get picked by
Jersey to handle this kind of entity. Instead, Jersey falls back to the
usual JAXB processing, which (of course) serializes as XML.
What I'd really like is an easy way to configure something like
"*/*+json" to use the JSON provider, but that doesn't appear to be a
legal pattern. Failing that, I'm looking for other ways to accomplish
this goal, including:
(1) Subclass Jersey's JSONJAXBElementProvider and use @Produces and
@Consumes
annotations on it for all my "x-xxx/x-yyy+json" media types.
(2) Avoid a direct Jersey implementation dependency by cut-n-pasting the
base class
into my own application, and adding all the appropriate annotations
directly.
(3) Some magical technique to configure this that I don't know about
already.
I'm kinda hoping for an early Christmas present of someone pointing out
a type (3) solution :-). But, without that, is my analysis of what's
going on correct? Any other approaches to suggest?
Craig