When considering the XMLHttpRequest payload, there are three obvious routes to consider.

1. responseXML -> pure data encoded in XML


2. responseXML -> pre-formatted html


3. responseText -> pure data encoded in JavaScript

Option 1 is attractive, as you can write the resource in a client agnostic way. The input and output communicate the current data in a known format. A fat Desktop client, or our web app can processes this in the usual manner.

Option 2 is probably the easiest to implement for simple cases. Once we have our response, we can just traverse our current web document and replace nodes with the same id. The downside is that our server side resource has to keep track of the presentation issues.

Option 3 is strikes a nice balance between reducing the time for client side development, client side XML processing, and server side stateful processing. Our resource will need to know how to marshall data into JavaScript variable definitions, but if the resource only services a single known application, then this may be a very effective route. Once the responseText is evaluated into live JavaScript objects, then they can inspect the old data and make updates accordingly. Then the elements can redraw themselves on the page.

Just to torture myself, I think I will start with Option 1 for a side work project I am doing.