Monday, October 21, 2013

Web Requests - JSON vs. Text

After doing a fair amount of work involving web GET requests and transmission of data in different formats, I've taken an interest in the question of performance between the different types. Initially, I planned on comparing two ajax calls, one that used a response type of JSON and the other plain text. I was so used to using jQuery that I forgot that on a level lower than the common javascript library, response types might not exist. After doing some short research I discovered that the XMLHttpRequest object (the native javascript object used for web requests) has a responseType method through which you can set the data return type. This sounded promising but as it turns out, Chrome doesn't support the method yet. Since I am relying on the Audio API for spatial audio, Chrome is currently the only browser I'm concerned about so if there is no difference between a JSON and a plain text ajax call other than an extra call to JSON.parse(), the question of performance lacks any interest.

In fact, since the response type method doesn't work in Chrome, the definition of a "json" vs. "text" get request simply becomes a matter of how the data is parsed when it is received. But, in either case (response type or no response type) the question of JSON vs. plain text is bigger than the javascript. The data itself depends on the expected return type and JSON data may be much larger than a space delimited format, especially depending on how much metadata you wish that JSON to contain. But, there is another trade off on the clientside even after space delimited data is parsed, and that is how it is accessed and used. So aside from the XMLHttpRequest call itself, when comparing the performance of a "json" versus "text" style of GET requests, you also have to take into account the alternative method of parsing and the size of the extra metadata. For small transmissions the metadata is most likely negligible in terms of both network latency and parsing performance. But with large amounts of data with nested JSON would the performance difference be noticable? Would the JSON parsing also be slower than string splitting on spaces and simply storing in arrays? Would the performance results be different for small or large amounts of data based on any initial overhead of each method versus their respective scalability?

And this is just the client side. Whether the data being sent is expected to be JSON or plain text obviously affects how the server has to prepare the data. Does writing a string of JSON carry more overhead than simply concatenating a list of space delimited values? Similar to the client side questions, the server-side has several variables of its own.

Also, perhaps the value of the metadata, though it may not directly affect performance after it has been parsed, should add more value to the json method in terms of which is "best", not just in terms of performance. Having nicely named properties in an all-in-one object would certainly boost code readability and aid in the development process.

No comments:

Post a Comment