The advantage of XHTML over JSON is that you don't need a specialized client to work with it. You can use the browser, which is a general-purpose client, and th

The advantage of XHTML over JSON is that you don't need a specialized client to work with it. You can use the browser, which is a general-purpose client, and that will benefit you hugely during development and testing. There's a whole world of tools for testing web pages, both browser-based and library-based, and all of that can be used with your service if you use xhtml representations. >Nope. In JSON only strings are strings. Numbers, booleans and null are Javascript numbers, booleans and null. I assume you've looked at a JSON message. On the wire, it's all strings. Null is represented by the four characters n, u, l, and l. It's the message parser that turns that into a real null, and an XML parser can do that too. I'm not saying that JSON doesn't have an advantage when your client language is javascript, but even in javascript the best-practice is to use a real parser for JSON rather than just eval. If you've got to use a real parser anyway, you can also use the xml parser that's built into the browser. Combined with a library like jQuery which gives you xpath-like retrieval it's pretty easy: <div id="article"> <dl> <dt>Title: </dt><dd id="title">Adventures in JSON land</dd> <dt>Authors: </dt><dd id="authors"> <ul> <li class="name">Jane Doe</li> </ul> </dd> <dt>Published:</dt><dd id="published">false</dd> <dt>Tags:</dt><dd id="tags"> <ul> <li class="tag">JSON</li> <li class="tag">Javascript</li> <li class="tag">data format</li> </ul> </dd> </dl> </div> Retrieve that into msg, and then: $("#title", msg) -> "Adventures in JSON land" $("#authors:first .name", msg) -> "Jane Doe" $("#tags li", msg).length -> 3 To be fair, an extra step is needed for turning true, false, and null into real boolean and null values. That's a solvable problem, and so is turning the xhtml into a javascript object just like the JSON parser does if that's what you want. Also, notice that I recommended the service be able to produce BOTH json and xhtml. Special-purpose clients can use the json representation, and general-purpose clients can use the xhtml representation. That gives you the best of both worlds, and the code that produces either/or from an internal data structure is easy and small so it's not likely to introduce inconsistencies between the two representations.