2 Replies Latest reply: Feb 22, 2012 5:13 PM by Jason Porter RSS

application/xml or text/xml?

Dan Allen Master

I'll kick off the question asking with the first one that happens to be on my mind lately.

 

I noticed that in both the kitchensink example in the JBoss AS quickstarts and the JAX-RS plugin for Forge, the REST service endpoints are configured to produce "text/xml". Why is "text/xml" used instead of "application/xml"?

 

I ask for a few reasons:

 

  1. Clients expect application/xml - the mime type application/xml is the defacto standard in most mime maps for an XML response (while it's a strange name, it's widely adopted)
  2. JAX-RS standardized it - there is a constant for both application/xml and text/xml in the JAX-RS API MediaType (originally I thought there was only one for application/xml)

 

Is there a good reason to try to swim upstream and push for text/xml? If we are going for the path of least resistent, it seems application/xml is a better choice.

 

According to the RFC-3023 spec (regarding media types):

 

   If an XML document -- that is, the unprocessed, source XML document
   -- is readable by casual users, text/xml is preferable to
   application/xml.  MIME user agents (and web user agents) that do not
   have explicit support for text/xml will treat it as text/plain, for
   example, by displaying the XML MIME entity as plain text.
   Application/xml is preferable when the XML MIME entity is unreadable
   by casual users.

 

The problem is that part that clients that don't get text/xml will treat it as text/plain, which can break some clients (clients users might be playing with in the early days of getting started). One example I found is that the Apache httpcomponents library issues requests with the Accepts header as application/xml but not text/xml, so I bumped into a stumbling block when writing an Arquillian client test until I figured that out.

 

Either way, the code should definitely be using the constant from JAX-RS rather than hard-coding the string "application/xml" or "text/xml".

 

I'll also add a second question. Why are we not mapping application/json by default as well? If we are advocating for the use of HTML5 (or, to be more accurate, JavaScript clients), shouldn't we be recommending application/json right from the beginning?

  • 1. Re: application/xml or text/xml?
    Pete Muir Master

    This is a hangover from the Weld Archetype that you and Steven did originally :-) It got copied into the AS 7 archetype, and from there to Forge. If you think we should be doing something else, and feel confident it's the right thing to do, please send a pull request, or file an issue in the github project :-)

     

    We could also produce JSON for sure.

     

    Note that I am in the process of upgrading the archetype to support full CRUD. This will include CRUD via REST. Also, Richard is probably upgrading the Forge support as he develops the html5 scaffolding.

  • 2. Re: application/xml or text/xml?
    Jason Porter Master

    I would opt for application/xml and application/json. I'm not sure when the last time was that I saw a text/xml. Despite what the RFC document says I've always thought "This is for programmatic consumption, readable or not. It's part of the/an application."