Tom Wang - Fotolia
Does reading XML while writing JSON make me a bad person?
I'm always writing JSON code, loving its flexibility and forgiveness. But when I call an external service, I want to be reading XML. Does that make me a bad person?
I've come a long way over the years in terms of software development. There was a time when all I needed was an HTML form on the client-side and a Servlet's getRequestParameter() method on the server and the world was my oyster. I am now much more enlightened. My current request-response cycles are Ajax based JavaScript calls, and the medium for my browser-based messages is a JSON string. But despite being an ardent advocate for delivering JSON based payloads, I find myself wondering if I'm bad person for turning my back on JavaScript Object Notation whenever I make a request for something from an external service.
A deep seeded hatred for anything extensible
I've always hated XML. It's too verbose, it's a bloated format, it forces applications to needlessly parse and unparse information that could much more efficiently be sent in a binary format, reading XML isn't nearly as easy as fanboys suggest, and troubleshooting XML syntax errors is a nightmare. At this very moment, I have applications that won't deploy out of my local Eclipse workspace because some XML validator can't validate against some external XSL file that doesn't exist. Not to get anthropomorphic with an OASIS standard or anything, but sometimes I think XML purposely taunts me.
But here's the thing, I've actually found my anti-XML bias softening when the headache of dealing with extensible markup is offloaded to someone else. For example, any time I'm playing with a RESTful API like the ones made available from Twitter or Google Maps, when faced with the choice of receiving JSON or reading XML back from my RESTful calls, it's with palpable shame that I find myself regularly deferring to the extensible.
In defense of middle-tier development
I know there's a big movement proclaiming the middle-tier dead, but I regularly find the need to perform a little bit of pre-processing on the Java EE side, especially when there are bits of data embedded in a service's RESTful response that needs to be hidden from the client. More often than not, the format of the RESTful response needs to be tweaked into a format that's easier for the web client to consume. When that's the case, and it often is, I want the external service I'm calling to send me some well formed XML, not a flaky JSON string.
There's something comforting about getting an XML response. There's an XSD, there's a clear definition of how the data will be structured, it's easy to feed the schema to your IDE or even a Gradle or Maven plugin and automatically generate the corresponding JAXB classes, and from that point on, all you have do to is code as you usually would. Reading XML is a safe thing to do.
Consuming XML from your REST based services is the programming equivalent of wrapping yourself up in a warm blanket and sitting in front of the fire. The XSD is a contract the service you are consuming has bound itself to, and you know it's not likely going to change. Your code knows how to handle it reliably, and you know that interacting with the external resource at that level isn't going to be a problem. Reading XML is good.
The hypocrosy of reading XML and writing JSON
But here's the rub. As a developer, I don't hold myself to the same standard I demand from the RESTful services I consume. I'm always adding properties to my object notations. I'm constantly changing the structure. I can change the JSON payloads my clients generate at any time I like, it will rarely cause problems for the code running on my server, and when I do make these adjustments, I don't have to feel like I'm pleading my case in front of a frowning judiciary, which is exactly how I feel when a small XML change requires me to update XSD files and regenerate hundreds of JAXB classes on all of the clients.
I'm always writing JSON, but my server-side preference is reading XML. The RESTful API services I write are filled with hypocrisy like this:
@Produces( MediaType.APPLICATION_JSON )
@Consumes({ MediaType.APPLICATION_XML })
And I'm wrought with guilt each time I code an HttpURLConnection like this:
con.setRequestProperty("Content-Type", "application/json");
con.setRequestProperty("Accept", "application/xml");
Everything I like about consuming XML is in diametric opposition with what I like about developing with JSON, and it makes me wonder if this duplicity makes me a bad person? I'm pretty sure it does. But what really compounds my guilt is that despite being fully aware of the waywardness of my ways , I feel no propensity to change. I'm will continue to demand well formed XML from the services I consume, and all of the clients that consume the content I produce better be happy with the flaky JSON strings that I deliver to them. I know it makes me a bad person, but I'm happy writing JSON while reading XML.
