← Back to team overview

openstack team mailing list archive

Re: XML and JSON for API's

 

Format wars are so tiring. What formats we Openstack should output is a marketing question, not a technical one. We should be trying to figure out how to do more formats, not fewer, because customers don't want us making choices that place constraints on them, especially when those are tied to religious wars like XML vs JSON.

I'll speak on behalf of my organization - Rackspace Internal IT. We've standardized on XML for backend work. We aren't spending much time debugging serialization issues and are pretty happy with our decision and aren't likly to change any time soon. People can argue JSON's merits all day, and at the point they try to tell me how to implement my solutions, all it does is annoy me, because format wars are annoying.

Customers want tooling that's flexible and doesn't try to force its opinions on them. So the obvious thing to do is support both JSON and XML, which isn't that hard. Web frameworks that can do it elegantly are a dime a dozen. The question we should be discussing is what to ADD to {XML, JSON}, not take away.

On 06/03/2011 04:37 AM, George Reese wrote:
A lot of the arguments against both XML and JSON seem to boil down to "here's why XML sucks..."

The reality is, for whatever reason, good or bad, a lot of people prefer to parse complex data in XML. There's a big market for it. Supporting both formats doesn't add horrible complexity.

-George


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.



Follow ups

References