2 Replies Latest reply on Feb 22, 2012 5:13 PM by lightguard

    application/xml or text/xml?

    dan.j.allen

      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?
          pmuir

          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?
            lightguard

            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."