Why JSON is Awesome
From The Socknet
The one true data-interchange format http://www.json.org/ .
JSON is the only data-interchange format used in the Socknet. It has specific constructs to deal with all the data types needed and is easy to use.
XML is not used because it has to be bent a little to support simple things like arrays. XML was never meant for data-interchange; it is a document language. The only reason it found its way into data-interchange jobs is that no other standard was as easy for human's to adapt to at the time. HTML programmers ruled the world.
You don't need to learn JSON. Your language has a library for it. If it doesn't, go ahead and learn JSON, write a library (possibly borrowing from some other language's library) and then forget JSON. That's the reason we use JSON. It requires very little thought.
In Perl
It equates to hashes and arrays. Booleans are the only special case, because Perl has no specific boolean type. This is important for compatibility because even though JavaScript, JSON's home language, treats "" and 0 as false, some languages do not (ahem, Ruby).
In PHP
It equates to associative arrays and indexed arrays.
In Ruby
Same as PHP.
In JavaScript
JSON is JavaScript. Lookup the eval method. However, there is a security issue to be considered here. Don't eval code unless you're sure it's safe. See the security considerations below.
In Flash
Same as JavaScript. ActionScript wishes it was JavaScript.
In Java
Strongly typed languages are more difficult, even awesome ones like Java. But it simply means you need to learn about a small set of classes. See http://json.org/java .
In the rest
Your library will almost certainly be very simple.
JSON requires no extra thought if a good library is used. In some libraries and languages actual constructs from that language are created. In others, very simple to use objects are created.
No Other Data-Interchange Protocol
There is no need to provide any other protocol, and it's important to have one standard.
But to answer some arguments:
JSON can't handle binary data.
It almost can, but it's not a good idea. Instead of passing binary data around, a better method is to pass around web URLs to that data.
What about namespaces, they sure help with the X in XML.
They do. JSON has nothing like namespaces. However, the concept is portable. See Namespaces.
Can't we just have another data-interchange format if we want to?
Please don't. The system is strengthened by having exactly one data-interchange format. If you want to waste your time, write a better JSON interpretter for your language than the one that already exists.
However, if you provide communications outside of the Socknet protocol, you are free to do that however you want.
JSON is YAML, so I could use a YAML parser right?
There's some sort of war about this. Tread lightly. Ensure that your library intends to parse and produce JSON. That way, if its creators discover problems, they'll actually fix them instead of saying "Well it wasn't really supposed to parse JSON anyway."
In addition, all of the examples of YAML I've seen don't look anything like JSON. So, I don't know what people are thinking. --Dan
What if I use XML to create a separate protocol between two services that discover each other through the Socknet?
Oh, sure, services can communicate however they like.
Security considerations
As mentioned above, there are security considerations in Flash's ActionScript and JavaScript because JSON is typically run through eval(). However, this security hole rarely comes into play, because Flash and JavaScript aren't generally used by the server. They are only used by the user's browser.
However, if the server intends to forward JSON data to the browser, it should parse it and then re-JSON it. If it has dangerous code in it, the parser will fail and the code should quit trying. If it has no dangerous code then it should parse fine and be re-JSON'd fine too.
The moral is: don't forward raw JSON from an untrusted source (such as another service or provider) directly to the user's browser.
