CELEBRATE EARTH WEEK
Save 40% on eBooks and Web Editions*—use code EARTH now through April 27. Shop now.
Publishers of technology books, eBooks, and videos for creative people
When a Web application makes a client-side request for data from a server (that is to say, uses Ajax), you have to select the appropriate format for the returned data.
For simple responses, plain text makes a lot of sense: It requires little effort to send from the server or handle in the client and has the added benefit of being rather secure.
Plain text is implausible, though, for situations in which more data is being transferred, particularly organized and nested data, such as the records being returned from a database query. For such situations, the logical and historical solution is XML (eXtensible Markup Language).
XML is still a standard and useful format, but it's considerably bulky, both in terms of the amount of data needing to be transferred (with all those opening and closing tags) and in terms of the amount of code required to parse out the individual values.
var data = eval('(' + JSONresponse + ')');
The second security approach is to try to guarantee the integrity of the JSON data.
Performing XMLHttpRequests has some built-in integrity, as those requests can only be made on the same domain. But there are ways around that limitation, and even without any circumvention, the client side of your Web application is still reliant upon the security of your server-side code. But what if you're not using XMLHttpRequests? The solution there is to simulate the same-domain restriction by having the client and server pass a token back and forth. The validation of that token would confirm that the communication is appropriate (and not, for example, being forged by a malicious site).