[
https://issues.apache.org/jira/browse/CXF-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628246#comment-13628246
]
Todd Orr commented on CXF-4959:
-------------------------------
While it's good to know I can set types on the JSONProvider, it might become
error prone as we have a large number of types. I would ideally like to either
a) use the @Produces annotation near the producing method as keeping the type
close to the usage would help highlight the relationship to developers, or b)
use a filter to dynamically determine the type being returned. B is more of a
catchall/fallback.
The relationship between these types isn't codified through a spec to my
knowledge. This appears to be a popular way for communicating the
domain-specific structure of said data be it json, xml, other; as well as
specifying version. As an example, github uses these vendor-specific
sub-subtypes in their API (http://developer.github.com/v3/media/). The
(admittedly small but rising) popularity of this approach has been driven by
pieces like http://barelyenough.org/blog/2008/05/versioning-rest-web-services/
and
http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http,
among others. It is true that there is some overlap using parameters.
I think that the difference would be expressed in the following example:
consider two methods that respond on the same URI. The difference between said
methods would be that they produce a "version 1 (application/v1+json)"
representation of a data type, and a "most recent (simply application/json)"
representation. If the client was tied to a particular representation, then the
client would be able to specify that it accepts only the application/v1+json
mimetype, whereas other clients could specify application/json and simply
receive the latest representation. This use case could be handled through
filters, dispatchers, etc., but there is a certain simplicity to simply
annotating a method, wouldn't you agree?
> Support hierarchical mimetypes
> ------------------------------
>
> Key: CXF-4959
> URL: https://issues.apache.org/jira/browse/CXF-4959
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Affects Versions: 2.7.4
> Reporter: Todd Orr
>
> I am attempting to provide a custom hypermedia model through the mimetype
> returned in a response. I would like to ensure that the Content-Type header
> reflects this while serializing the data according to the best fit message
> body writer. Unfortunately, this doesn't work. I have tried two approaches:
> 1. Annotated the service method with @Produces("application/my-type+json")
> 2. Used a ContainerResponseFilter to set the Content-Type header according to
> the data type being returned (effectively the same goal as #1)
> The result of either approach is not good, but they fail differently.
> 1. Results in a 404 as the client is sending an accept for application/json
> 2. The serialization fails with a no message body writer found error
> I'd expect both of these approaches to work as follows:
> 1. CXF determines the best match given the available producers. For example,
> application/my-type+json is clearly applicable under application/json, so it
> should match application/json request Accept headers as well as more specific
> Accept values.
> 2. The message body writer for application/json should apply to
> application/my-type+json since the latter is clearly applicable under
> application/json.
> I believe the argument against this request would include a plea for forcing
> the client to specify exactly what it wants returned and having the server
> rigidly behave. However, I think this falls under the purview of the
> Robustness Principle (Be conservative in what you send, be liberal in what
> you accept). It would be a much better experience to implement something akin
> to what I have described.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
