mca blog

a while ago, Paul James' post on why XML is not a data transfer format caught my eye. as someone who works with XML a lot, i didn't really 'get' the point of the post. i figure XML is a perfectly acceptable format for sending data back and forth. esp. since so many client and server libraries have robust tools for handling XML documents including validation (DTD, XSD, Schematron) and transformation (XSLT, XSL-FO, etc.).

but recently, i've seen some light. to the point - XML is not the *only* data transfer format.

yes, XML can be verbose, but is is any more 'tag-heavy' than ATOM? i think not. in the past, i used to struggle with deciding on transfer formats since it was a 'set in stone' decision due to the way i built web applications. once the format was set, all code was written to that spec. changing it would be difficult and time-consuming. it would also cause lots of sturm-und-drang for clients.

but now that i understand the media type constraint outlined in the REST pattern, it is not such a big deal anymore. by building the web app to support multiple media types for the same resource, deciding on a 'be-all-end-all' data transfer format is no longer needed. sure, we can start with one format (XML, if you like) and make sure all is working well. but, since we designed - from the start - to support multiple media types, it is not such a big undertaking to add a new media type (JSON, ATOM, etc. to the mix. then clients can pick what they prefer - what works best for *them.*

see, i'm getting it!