JSON vs. SOAP :: A War Worth Waging?

by M. David Peterson

Update: Ric (who links to JSON.com, which seems to be a new blog about JSON-related items... SUBSCRIBED!) provides a nice summary in a comment below,

XML is
1) DOCUMENT centric
2) Well known with lots of tools
3) FAT (SOAP is)

JSON 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!

[Original Post]
... and then it hit me...

ongoing � JSON and XML

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...

18 Comments

Dan Sickles
2007-01-03 12:58:32
Food fight!
M. David Peterson
2007-01-03 13:24:36
@Dan,


As long as its apples against apples... I'm in! ;) :D

Michael McGranahan
2007-01-04 12:36:58
Ah, a debate about what to debate... a meta-debate?


As of SOAP 1.2, the SOAP acronym no longer stands for anything. This reflects the intention that SOAP simply be an XML-based message exchange framework. It's completely possible to define a JSON-based message exchange framework, but JSON itself does not do that.


Viewing JSON as lightweight XML makes more sense to me than as lightweight SOAP.

M. David Peterson
2007-01-04 20:18:13
@Michael.


>>Ah, a debate about what to debate... a meta-debate?


That sounds about right ;)


>> As of SOAP 1.2, the SOAP acronym no longer stands for anything. This reflects the intention that SOAP simply be an XML-based message exchange framework.


Hmmm... not sure that one is going to fly to well. SOAP, no matter how its later defined, will always be SOAP in the mind of the developer.


I do recongize that things very much evolve past what their original acronym was intended to suggest (e.g. PHP doesn't exactly equate to Personal Home Page like originally intended) but I have a hard time buying into the idea that a protocol originally designed as a form of remote object serialization can successfully pull off the "Don't let the acronym fool you. It's about messages, not objects."


Guess time will tell.


>> It's completely possible to define a JSON-based message exchange framework, but JSON itself does not do that.


Agreed. If I was suggesting it as a replacement for SOAP, this would then require a much more elaborate system of checks and balances. I'm not suggesting that at all. Thus the lightweight comparison.


>> Viewing JSON as lightweight XML makes more sense to me than as lightweight SOAP.


How so? For example, how would one go about using JSON to create a document that could be parsed and rendered (without help from a Javascript function) by a browser that reflects the same functionality provided by direct rendering of an XML document, whether that be XHTML or raw XML that uses an xml-stylesheet PI?


XML does a great job of representing documents. JSON does a great job of representing objects. Sorry, but I just don't see the comparison.

Kurt Cagle
2007-01-05 07:40:55
I'd put the kibosh on this one right now. SOAP has, IMHO, become an extraordinarily heavy-weight object with very clearly defined semantics for identifying message transport information. Such information makes a great deal of sense in areas where SOAP is used heavily (financial transactions, primarily) where being able to authenticate, audit, and maintain some sense of transactional integrity are all very important.


The danger I see with pitting SOAP against JSON is that JSON is, to me, simply a somewhat anemic XML format with neither attributes nor namespaces - simpleXML with curly braces, essentially. To express what SOAP is capable of expressing in JSON would entail a clearly defined schema with all kinds of potential for namespace collision in a language that doesn't even recognize formal schemas, and would have enough security holes that you could drive a few Mac trucks through.


I see JSON messages as being roughly the equivalent of an IM message (or SMS) while SOAP is the equivalent of a special couriered Fed-Ex package carrying contracts. Yes they are both messages, but the similarity ends there.

M. David Peterson
2007-01-05 09:12:18
@Kurt,


>> The danger I see with pitting SOAP against JSON is that JSON is...


Ummm... I guess the chosen title was simply too hard to overcome the fact that I happen to agree... You can't pit them against each other.


That said, you can't pit XML and JSON against each other either (I know we both agree with this point), though if you are going to make an attempt at clarifying what JSON should be used for, the comparison againsts XML makes absolutely no sense (again, I know we both agree with this), yet the comparison against SOAP, in terms of a *lightweight* alternative when you don't want or need the contract-first approach and all of the validation that comes along for the ride, does make sense when you are attempting to invoke remote processing of objects.


You wouldn't use SOAP for marking up a document (though you could easily use it to wrap a document up and send it to somewhere else as part of the payload) in the same way you wouldn't use JSON to markup a document. You would, however, use JSON to represent a lightweight serialization of an object that can be packaged up and sent to a remote location for processing, and in the same sense, you would use SOAP to perform the same functionality, yet SOAP (obviously) goes WELL beyond what JSON would even want to attempt.


So, once again... Use SOAP for heavyweight processing of objects, JSON for lightweight.


Seems pretty clear cut to me...

len
2007-01-05 11:39:20
I lose it with the 'don't need no stinkin' binaries' arguments. These people don't work with graphics or where they have, they fail and can't figure out why.


Binary XML is a fact of life in the 3D market particularly when the data goes to the mobile systems.


JSON is a simple solution for simple problems. Because a lot of network messaging is pretty simple, it will find a broad but shallow pool to breed in. Just don't call it The Ocean and start building boats.


Multiple formats are a fact of evolution. Bray is wrong. He wishes he were right and if he keeps saying it long enough to enough crowds, some percentage will accept it and selling into the CIO markets will be easier for him but he's wrong and the IT guys will take long lunches while the CMO guys work long hours.


This is the market warping the design. Joshua Smith from KAON made an astute observation on the www-vrml list in response to my question as to why one would consider building a separate network (yes, babs, abandon the Internet and the Web) for virtual reality:


"Multicasting is fundamentally incompatible with the current business model of the internet. Since the net is built on a bunch of point-to-point POTS style connections, to implement multicasting across the backbone, the ISPs need to do LOTS more transmitting. It frees a single server to swamp the ISPs outbound channel with far more traffic than that server could ever produce over a unicast connection."


So when I see these replies to JSON vs XML and 'the fight is over', I know I'm reading a marketing blog.


It's NEVER over. Just managed to one goal or another depending on who has the upper hand at some particular tick in the simulation.

M. David Peterson
2007-01-05 12:15:21
@len,


>> I lose it with the 'don't need no stinkin' binaries' arguments. These people don't work with graphics or where they have, they fail and can't figure out why.


Binary XML is a fact of life in the 3D market particularly when the data goes to the mobile systems. <<


An interesting point, and one I don't think can be argued by anyone who knows what they're are talking about (like you, for example, though you obviously wouldn't be finding yourself arguing against your own point ;) in this space.


I'll be the first to admit that I do find it hard sometimes attempting to defend the importance of "human-readable XML." Don't get me wrong -- I do believe it is important, but not SO important that is MUST ALWAYS be text. I mean, let's face it... Once the XML has been parsed, it no longer matters if the source is text or binary. If I can use the same tools to reference the content (e.g. XPath) and the same tools to transform the content (e.g. XSLT), and the same tools to render the content (e.g. a browser, or 3D engine, or whatever else), and the only difference in all of this is that,


a) I need a binary XML parser.
b) I have to give up the "luxury" of being able to read the source directly without first converting it to text...


Then who really gives a rip?


BINARY != EVIL!


EVIL == EVIL, and the only potential "EVIL" in regards to binary XML is the fact that I would need to invest into a binary parser, though something tells me a binary XML parser will be as prevalent in 10 years as a text XML parser is today -- actually probably even less.


Of course, there are those who will claim "binary XML holds potential of becoming proprietary, and proprietary is evil" to which my own response would be...


"Huh?"


Binary XML is just XML thats, you know, in binary format instead of text format. In other words, its already been serialized from something a human can easily read to something a computer can easily read. And anybody who understands how a computer works, understands that "text" is just an illusion, and an illusion that can easily be reproduced again, and again, and again, ESPECIALLY if the binary format just so happens to be oh-so-eerily close to well known tree representations of the data it represents, and can use languages we are all already familiar with to access that in which we have interest in accessing.


So here's my question to LandO'XML,


Tell me again: What's wrong with binary XML?


Considering the fact that one can easily create tools (actually, they already exist! They're called "parsers"...) in which can easily and quickly render the binary back into its text representation for all of the "View Source Generation" to peer into until our little view source heart is content -- I'm sorry, but I'm just having a hard time trying to remember why the "text only" argument has absolutely ANY validity in ALL cases at the moment.


In many cases I think it does... But all? Well, somebody care to refresh my memory?

Kurt Cagle
2007-01-05 12:42:23
I think there are other aspects to the JSON vs. (fill in the blank) that will change the balance considerably. One of the bigger ones is E4X. JSON has made significant inroads at this point less because of its size and more because of its parseability. DOM parsing is ... unpleasant at best, and once parsed, DOM structures are a pain to navigate without fifteen letter commands and a fairly in-depth knowledge of XML structure.


E4X on the other hand is making some serious inroads in that space , however. E4X parsing of XML is much faster than the equivalent DOM parsing, the objects are considerably lighter weight, yet the navigation is not all that radically different from the Javascript objects, one of the big advantages that JSON offers. For instance:


var car = <:automobile>
<:geartrain>automatic<:/geartrain>
<:color>Electric Blue<:/color>
<:make>Saturn<:/make>
<:model>Ion<:/model>
<:year>2007<:/year>
<:/automobile>;
var ccar = {
geartrain:Automatic,
color:Electric Blue,
make:Saturn,
model:Ion,
year:2007
}
print(car.color);
=> Electric Blue


print (ccar.color);
=> Electric Blue


car.engine = "Dual Cam"
ccar.engine = "Dual Cam"


print (car.engine == ccar.engine)
=> true
for ([key,value] in ccar){
print(key+":"+value);
}
=> geartrain:Automatic
=> color:Electric Blue
=> make:Saturn
...
for ([index,value] in car.*){
var key = car.*[index].localName();
print(key+":"+value);
}


The bit of clunkiness in the first line:
var key = car.*[index].localName();


is more than made up in searchability:


car.(year == 2007)


will return the car instance while


car.(year == 2006)


won't. There is no corresponding capability within JavaScript objects.


Downside, for now, is that E4X isn't yet supported in IE, only Firefox and ActionScript, but I suspect that it will end up in the IE 7.5 release, and you're seeing similar structure appearing in languages such as PHP, Ruby, Java, and in slightly different form Microsoft' Linq. It's an ECMA standard, it reasonably lets you bridge the lightweight nature of JSON with more complex structures such as SOAP, and it keeps you in the XML paradigm.


Over the years, I've found that when you have two technologies of roughly equal capabilities, it will be the one that can better bridge to the emerging infrastructure that will be dominant, regardless of any other superiority. I've also found that betting against XML is generally a way to end up broke - it causes an underlying phase shift in development that usually ends up altering the architecture of the entire system. So even though at the moment I would give the edge to JSON by its ubiquity, I think this will likely end up shifting pretty dramatically even within the next year as e4X or other objective XML technologies gain traction.

Kurt Cagle
2007-01-05 12:52:48
Binary XML is pretty much a foregone conclusion in terms of need, the only question is whether you can get enough people in the same room at the same time to agree on WHAT that binary format is going to look like. John Schneider (who not coincidentally was one of the key people, along with Mozilla architect Brendan Eich to develop E4X) also put together a binary XML format that now appears to be the best candidate, and once you write serializers to other XML formats (such as Java or .NET XML streams), then you can reasonably provide at least a front-gate portability until such time as Java or .NET create the corresponding general binary format into their parsers and processors.
M. David Peterson
2007-01-05 13:10:05
@Kurt,


You know, why is it that I keep getting all excited about E4X and then forgetting that it exists? Force of habit?


E4X, ROCKS!!! I guess the point you bring up regarding lack of support in IE is pretty significant, though if what you are suggesting turns out to be the case (in regards to IE7.5), I can easily see E4X becoming the defacto standard that bridges the gap that in which makes JSON such an attractive lure in the first place.


In other words, I think you're spot on with your analysis... Thanks for the reminder!!!

M. David Peterson
2007-01-05 13:13:26
>> Binary XML is pretty much a foregone conclusion in terms of need, the only question is whether you can get enough people in the same room at the same time to agree on WHAT that binary format is going to look like. <<


Ahh... point well taken.


>> John Schneider (who not coincidentally was one of the key people, along with Mozilla architect Brendan Eich to develop E4X) also put together a binary XML format that now appears to be the best candidate, and once you write serializers to other XML formats (such as Java or .NET XML streams), then you can reasonably provide at least a front-gate portability until such time as Java or .NET create the corresponding general binary format into their parsers and processors. <<


Hey, I'm all for it -- and if the Java and .NET camps put some muscle behind it, providing a transparent conversion between text and binary, then what's not to love about binary XML?


Bring on the binary, baby!!! WOOHOOOOOOOOOO!!!! :D

Ric
2007-01-05 20:22:44
XML is
1) DOCUMENT centric
2) Well known with lots of tools
3) FAT (SOAP is)


JSON 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.)

M. David Peterson
2007-01-06 06:22:34
@Ric,


Nice summary! Thanks!

Taylor
2007-01-06 07:42:27
>If you need it, use it, if you don't, don't.


That's the war. SOAP'sters ~always~ need it!

M. David Peterson
2007-01-06 08:02:29
@Taylor,


> That's the war. SOAP'sters ~always~ need it!


:D Point well taken :D

Ric
2007-01-08 18:46:07
Thanks for this link - I posted a reponse at http://www.json.com/2007/01/08/pay-no-attention-to-the-man-behind-the-curtain/ - but it looks like the trackback does not work.
If anyone want to participate on JSON - let me know!
M. David Peterson
2007-01-10 00:47:57
@Ric,


Right on... Am looking forward to where you take the site/content!