1) DOCUMENT centric
2) Well known with lots of tools
3) FAT (SOAP is)
1) SERIALIZATION of a structure
2) Less known and not so many tools
3) Thin (No client side libraries needed)
JSON is also a form of remote scripting (no XmlHttp request)
Xml is much more mature: quite a LOT of thought on namespaces, unicode, schemas, external file inclusions, and binary attachments (I am working on Base64 encoding in JSON, so that should be not an issue.)
Sounds about right to me. Thanks, Ric!
… and then it hit me…
The Arguments Are Over � There used to be an argument about whether platform-neutral, language-neutral data formats were important, or whether distributed objects were the right answer. That’s over: HTML, XML, JSON. �
There used to be people who argued that network interchange formats shouldn’t be text-based, but use binary where possible, for efficiency. That’s over: HTML, XML, JSON.
When SOAP is overkill, is JSON the lightweight answer? Seems to me it’s at very least a possibility, and if I were an Anti-SOAP kind of guy (which I’m not, by-the-way… SOAP has its place. If you need it, use it, if you don’t, don’t.) the “war” I would be waging would not be JSON vs. XML, and instead JSON vs. SOAP.
Think of it this way,
JSON: Java Script Object Notation
SOAP: Simple Object Access Protocol
Now before I get myself in any trouble, I’m not advocating that a war be waged against SOAP (please see note from above regarding my feelings on this topic, as well as this three part article on my personal blog for more info.) What I am suggesting, however, is that if you are going to wage a war of any type, shouldn’t you at very least be comparing apples to apples?
Just food for thought…