Sean Landis wrote:
We'd like to have a single resource and URI (GET http://host:port/service/foo)
and return HTML if the client is a browser, and return something more
machine friendly for a web service client. We use a lot of XML with JAXB
and we have been specifying APPLICATION_XML for JAXB. It would be
nice if there was some better (more distinguishing) media type for that.
The problem of course (as you say) is that text/xml is too generic and
not distinguishable. It could stand for a whole host of xml
vocabularies. I kind of like what the Restful Web Services book has to
say on this:
"Although I've presented this [creating custom XML vocabularies] as the
last resort, that's certainly not the common view. People come up with
custom XML vocabularies all the time: that's how there got to be so many
of them. Almost every real web service mentioned in this book exposes
its representations in a custom XML vocabulary. Amazon S3, Yahoo!'s
search APs, and the del.icio.us API all serve representations that use
custom XML vocabularies, even though they could easily serve Atom or
XHTML and reuse an existing vocabulary.
Part of this is tech culture. The microformats idea is fairly new, and a
custom XML vocabulary still looks more "official." But this is an
illusion. Unless you provide a schema definition for your vocabulary,
your custom tags have exactly the same status as a custom value for the
HTML "class" attribute. Even a definition does nothing but codify the
vocabulary you made up: it doesn't confer any legitimacy. Legitimacy can
only come "from the consent of the governed": from other people adopting
your vocabulary." (The Building Blocks of Services -> Representation
Formats -> Other XML Standards and Ad Hoc Vocabularies)
I tend to stay away from text/xml for exactly the reason you've
described. It's just too generic and not distinguishing enough. And,
of course, browsers like firefox by default love text/xml over other
formats. So, for what it's worth, I use a mostly custom content type
which specifies the "vocabulary" of the XML in use.
For example, since our clients are typically swing based, we do a lot of
serialization using XMLEncoder. Instead of a generic media type, I have
adopted this content type which seems to make sense (to me):
application/x-java-serialized-object;encoding=xml
The base application/x-java-serialized-object part is a somewhat
"standard" mime type extension typically referring to java objects
serialized with ObjectOutputStream. So, I just "extended" it by adding
on my own parameter, and this works for me and might work for others
someday too. And, obviously this still allows browser based clients to
use the service as well.
Anyway, so I guess the point is, don't use text/xml (or other generic
xml content types) for your JAXB representations. Use something more
standard/specific or in the */x-* family, which will of course play
better with browsers. Amazon has some, for example, */x-amzn-* content
types.
text/xml as a content type standard was probably a mistake. Too bad for
us really.
Adam
p.s. I'm starting to be a fan of the whole "filename extension" way of
specifying the content type by the client. Ie. .html for html, .jxml
for the XmlEncoder generated XML, .json for JSON, etc. Hesitant to
using this method originally, I'm definitely warming up to it and think
it makes sense because generally clients usually know which type of
representation they are going after. I just think it makes the URI more
explicit and meaningful, which of course is a good thing.
