JSON vs. XML vs. XHTML
I've come to the conclusion that, abstracted properly, I really don't have a preference as to which one you use. The book will stay as messaging transportation method agnostic as possible, only using one method over another when it makes the most sense for that particular use case1.
- Server-side validation
- The result should return in a format easily parsed by JavaScript in order to highlight problem areas and provide a little metadata (such as the answer to "did it pass?"). Though XHTML, technically can get parsed as XML, the JavaScript then relies heavily on the markup structure of the page itself, which can lead to Very Bad Things. For this usage, either JSON or XML would work much better, but which one I would leave completely up to you.
- Content replacement
- By content replacement, I mean swapping out a large block where it really doesn't matter as to the contents (ie. navigating blog posts or looking up a word in reference materials). This one doesn't really matter which way you go about it. Even just swapping
innerHTMLwith theresponseTextwould work fine if you really wanted to go that route. - General server-side to client-side communication (and vice-versa)
- Same story as with server-side form validation: it really doesn't matter...unless you either need to squeeze every last bit of performance out of your application (go with JSON), or you need output easier to consume by 3rd party applications (go with XML).
As a personal preference, I generally stick with (but no longer get into religious arguments about) using XML for the following reasons, in no particular order:
- Easier to read when viewing the raw traffic
- Easier to use from other, non JavaScript tools (though JSON libraries exist almost everywhere now)
- I would rather use a transport method that, by default, does not have even the slightest chance of executing statements when parsed.
- Habit
- More portable, since many already-built applications need to keep the current language versions, many older installations of which do not yet have JSON libraries (which you can usually include, yes...but that gets into other issues)
The JSON vs. XML argument has gone on entirely too long for something that doesn't even really matter when it comes down to it. At this point, I might even implement some of the examples in a way that you can just change out the method you want to use and have it switch on the fly, since the architecture of the application that matters to the examples won't know or care how the data arrives or gets sent, anyway.
- 1 All of these cases assume the normal, necessary error checking and validation routines before actually inserting anything into the page itself.
Labels: advanced ajax
3 Comments:
I'll admit to being ignorant of JSON as I have always used XML.. but isn't JSON just serialized javascript objects?
If it is, that kinda scares me..
Okay the more I think about it.. I guess JSON is really not that bad.. So long as you run it through a parser, as opposed to just EVAL() the results you should be fine.
That same parser could just as easily pull in XML..
Really, they are fairly similar.. the main difference being the flavor of angle brackets or braces it uses to delimit the data.
XML is probably more complex in the long run because it is a fully functional markup language where as JSON isn't..
There are other solutions like YAML but really if you need a markup language then go for XML..
Really the JSON vs XML arguement in most cases isn't valid simply because they are used for different things.. When you try to use them both for this kind of application JSON is probably simpler to use but either works just fine..
"I'll admit to being ignorant of JSON as I have always used XML.. but isn't JSON just serialized javascript objects?"
If you check json.org, it defines the entire language on the front page.
The biggest risk in using JSON (in my mind, at least) comes into play when consuming 3rd party JSON, which may contain objects. Obviously, you definitely do not want to evaluate this in the context of the window object, which happens more often than not just given the purely non-this nature of the "this" reference.
That said, you do have the ability to validate whatever comes from the server, assuming you don't just include <script src="whatever"...in your header. You can then not only cache the results on the server, but clean it of any objects if you only expect arrays of data.
"If it is, that kinda scares me.."
I had the same reaction when sitting down with Terry at the PHP Conference. He asked me why I would prefer XML, and (completely justifiably) called my first, gut reaction complete bullshit. It gave me the willies, but that doesn't make a valid application design argument. When challenged with this, I started thinking about how I also don't necessarily know that only my JavaScript will parse the output, so XML makes more sense for that. When your application controls all of the actual JSON and properly (emphasis on "properly") escapes any of the strings getting sent along the way, the threat of code execution suddenly goes away, since any XSS vulnerabilities in the application would by definition result in code execution anyway.
"Really the JSON vs XML arguement in most cases isn't valid simply because they are used for different things.. When you try to use them both for this kind of application JSON is probably simpler to use but either works just fine."
Exactly. Like I posted, even though JSON makes for lighter transport and (in general) much faster parsing, I still prefer XML for the reasons listed. Really, I suppose I could code an entire project using XML for development and switch to JSON for production where possible (assuming proper QA, of course :-) ).
Post a Comment
Links to this post:
Create a Link
<< Home