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