You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Sergey Beryozkin (JIRA)" <ji...@apache.org> on 2013/04/11 11:19:15 UTC

[jira] [Comment Edited] (CXF-4959) Support hierarchical mimetypes

    [ https://issues.apache.org/jira/browse/CXF-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13628783#comment-13628783 ] 

Sergey Beryozkin edited comment on CXF-4959 at 4/11/13 9:17 AM:
----------------------------------------------------------------

Definitely agree about supporting hierarchical subtypes, in fact there is some limited support: for JSON (or JAXB) provider you'd just configure them with "application/\*+json, application/json" and assuming that the wildcard in application/\*+json catches the variation then it will do for you...

I think I can update a media type compatibility check code slightly, if we have "application/x+json" or "application/json+x" then it must be compatible with application/json, etc... 
   
                
      was (Author: sergey_beryozkin):
    Definitely agree about supporting hierarchical subtypes, in fact there is some limited support: for JSON (or JAXB) provider you'd just configure them with "application/*+json, application/json" and assuming that the wildcard in application/*+json catches the variation then it will do for you...

I think I can update a media type compatibility check code slightly, if we have "application/x+json" or "application/json+x" then it must be compatible with application/json, etc... 
   
                  
> 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