JSON in non-Javascript applications

I'm looking to persist and retrieve a large amount of key-value pair(s) type data over the wire. Is it appropriate for me to use JSON for this purpose against XML?

Is JSON used in non-Javascript applications?

Are there advantages using JSON for this purpose over good 开发者_如何学Goold XML?

JSON is fine for this use, and will be more compact than XML. (We're using it extensively in a non-Javascript application, and allow consumers of our REST web services to specify if they want the data in XML, JSON, or even XHTML representations.)

Update: Where bandwidth is a concern, you can probably get a 50-70% compression by GZIP-encoding/decoding your XML or JSON. See GZipStream.

Because JSON is widely used by web application servers to communicate to Javascript in the browser (AJAX) there are lots of JSON encode/decode libraries for every language that you can imagine. For instance Python has 6 different implementations to choose from.

The main advantage to using JSON for a "large amount" of data is that the parsing time to decode the data is quite a bit less than parsing XML. Now it is possible that your key-value pairs are simple enough for parsing time to not make a difference, but if the values have any kind of composite objects in them, then JSON will be faster.

I find JSON less verbose than XML and there is a very nice database in development called CouchDB which lets you store/search JSON documents directly.

I agree with the others regarding JSON's usability, but with one caveat: JSON does not allow you to provide additional information about the data. If all you want to use is name-value pairs, where all values are strings, JSON is fine.

OK, somebody has probably just voted me down, because the JSON spec differentiates between strings, numbers, booleans, and arrays. But my response to that is: what sort of a number are you getting? A 32-bit integer or a thousand-digit floating-point?

XML, by comparison, allows you to store metadata in attributes. For example, the xsi:type attribute, as defined by XML Schema. Both side still have to agree on what the attributes mean, of course, but there are a lot of cases where metadata is important.

Whether it is best for you will depend on your priorities, such as, speed, or flexibility.

I had moved a C# application to use JSON because speed was the most important issue for me. I would serialize the data myself on the server and remove anything redundant, such as the name of each property in order to speed up my transfer, and I found that time to send a request to the server, get the response and process was faster with JSON than using a webservice or returning XML.

To deserialize, from C#, you have several options at http://json.org.

So, before you decide to make the change you should have some unit tests and then get some numbers, by making the same client -> server -> client call about 100 times, to get better results.

You should have all the tests in the same test class so the tests can run straight through, to reduce the chance that the server load will issues.

If you will need the flexibility of sorting or processing in other ways, such as using XML LINQ, then you either convert the information to a list and use LINQ, but, again, you may want to add tests to see what the impact of this would be, on your application.

Basically, I believe that if you have time, before making any architectural changes test first, and then decide if making the change makes sense, based on the numbers.

Of course, in fact JSON is much better than XML, for the following reasons:

• APIs for reading/writing are much (much much) simpler.
  • Retrieving values is as simple as reading keys from a dictionary.
• It's less verbose, more easily readable by mere mortals.
  • Which also means that huge data take less space and less time to parse.

It is more compact than XML, and faster to parse in some cases. So I normally prefer it.

On the other hand, XML does solve a few spec problems by providing solutions (f.e. encodings).

However, I can just write in my spec "You must only use UTF-8" and then the encoding specifications problem is solved.

Basically JSON can be used if you need a simple key/value or nested key/value/list structure, and want the common problems of escaping and delimiting solved for you, with many parsers available.

I wrote at least one protocol using JSON, and the users of it never complained about using JSON instead of XML, despite being on Microsoft.NET :)

IMO, if you are going to persist things and want to have the possibility to upgrade the application (which is virtually always the case), you should create your serialization code manually, and create a documented file format. Otherwise you're up for big trouble at some point.