6 ms·
Don't limit yourself to JSON. Your dislike of XML does not mean that JSON is always the right answer. Instead, write code that flexibly can render to any of a s
by MostAwesomeDude 13y ago
Don't limit yourself to JSON. Your dislike of XML does not mean that JSON is always the right answer. Instead, write code that flexibly can render to any of a set of formats, and use content negotiation to determine which format the user agent wishes to consume. This lets you do things like let the read-only portion of your API be accessible via browser, and it will future-proof you.
- arethuza 13y agoI did think that the criticism of XML for being hard to parse was a bit odd. Although I generally prefer JSON for simpler stuff XML is pretty easy to parse and sift through with XPath.
- _pmf_ 13y agoIt has to do with the awful XML generated by automatic tooling (SOAP by WCF and JEE). Hand-generated XML can be just as nice as using hand-generated JSON, and on the other hand automatic domain-model-to-JSON mapping can be as ugly as any XML monstrosity.
- peterwwillis 13y agoThough for the same dataset, XML will be slower to parse. For performance's sake use JSON.
- arethuza 13y agoI suspect that depends a lot on what platforms are used at the client and server.
- _pmf_ 13y ago> Though for the same dataset, XML will be slower to parse. For performance's sake use JSON. Loading a huge JSON file is almost certainly slower than using a SAX parser for a huge XML file. Maybe there are SAX like approaches for JSON, too.
- icebraining 13y agoYes, it's called "streaming". Like in XML, you can also used a mixed approach. See e.g. https://sites.google.com/site/gson/streaming https://sites.google.com/site/gson/streaming
- veesahni 13y agoMost languages have the concept of arrays and hashes, which map unambiguously & idiomatically to JSON via generic serializers. Creating idiomatic XML, on the other hand, is a little more tricky. Should something be a tag or an attribute? What should it be named?
- jfaucett 13y agowhen he says "use JSON where possible XML only where you have to", I thought it was funny, like developers out there are just dying to use this verbose behemoth instead of its terser cousin json. But anyways, I agree with everything you're saying just wondering if there actually are any devs out there who just adore some sweet XML (seriously) ?
- veesahni 13y agoOP here. I got an email with an interesting argument on the topic. Paraphrasing: Today JSON is hip, tomorrow may be something else. By supporting XML by default and using XSLT to translate it to alternate outputs, you're able to support multiple formats without having to modify your software itself. Ofcourse, this does come with the cost of having to maintain XSLT files. To businesses that need to support multiple formats (enterprise requirements?), XML + XSLT sounds like a fair approach - it allows you to simultaneously create idiomatic XML & JSON
- dragonwriter 13y ago> By supporting XML by default and using XSLT to translate it to alternate outputs, you're able to support multiple formats without having to modify your software itself. By separating out the rendering-to-an-output format from the basic logic of the application, you get similar benefits without creating a dependency on XML handling libraries and requiring another implementation language (XSLT) for the rendering component.
- jes5199 13y agoThere's no benefit to using XSLT instead of just writing code to transform your data into another format.
- icebraining 13y agoI'm not a fan of XML, but I do like RDF, and unfortunately RDF/XML is the most common encoding format.