Dave's identified the need for a credit history service, providing a list of transactions. Javascript resources are limited, so the entire HTML is created server-side, and the browser application only has to morph a DOM element with the entire HTML response.

What format should be used for server responses?

Have the server generate HTML snippets to be displayed in the browser. In this approach to Browser-Server Dialogue, the server-side service outputs some HTML, which is picked up by the XMLHttpRequest callback function and an element then morphed by setting its innerHTML property to the response HTML. In general, the server-side is application-specific because the HTML response is closely tied to the application's display style.

The XMLHttpRequest allows callers to retrieve responses as either XML or plain-text. With HTML, it's usually easiest to retrieve it as a plain-text string. If the HTML is a pure XHTML document, XML is also an option, but usually that's not the case because there' no need for a header section. The entire response can be as simple as "<strong>You Win!</strong>". That's not an XHTML document because there's no <xml> tag, nor HTML header and body sections.

HTML Messages should be used with caution because they couple server-side services with browser display. That means it's difficult to develop the tiers in parallel. In maintenance, if you change the display by altering its initial HTML or any Javascript manipulation, you often need to change the HTML-generating service too. There's also a risk on the server-side that you might be coupling business logic with HTML generation. So when might an HTML Message be appropriate?

Typically, HTML Messages rely on a block-level element existing in the DOM, often a div or form. The HTML message will contain a specification for the entire contents of the element. Some of the XMLHttpRequest wrapper libraries, such as JAH/AHAH and Sack, support HTML Messages by letting the caller directly state a DOM element as the callback destination instead of the usual callback function. When the response returns, the DOM element is automatically morphed with the service's response.

A variant of this pattern is "Behaviour Message"; see “On-Demand Javascript”. Also, note that HTML Messages almost flow from server to browser; you'd rarely need to upload an HTML Message back to the server.

In the extreme, the service could generate HTML for the entire document, making it similar to a conventional page refresh. In practice, you'll usually want to limit the HTML's level of granularity to well-defined, distinct, page elements. For example:

Digg Spy responds with the full HTML to be displayed as well as some meta-content at the end. The results are fetched periodically - filldigs() is triggered by the recurring lastdigs(). filldigs() executes an “XMLHttpRequest Call”, extracts the HTML from the full response, and morphs the results panel using its innerHTML property:

    function startlastdigs() {
      window.setInterval("lastdigs()",15000);
    }
    function filldigs() {
      ...
      s.open("GET",url2,true);
      s.onreadystatechange=function() {
            if (s.readyState == 4) {
          ...
          b = responsestring2.split(split);
          ...
          document.getElementById('diggspy').innerHTML = b[0];
          ...
        }
      }
      ...
    }

Sending an HTML message is like sending a photograph - there's a lot of visual detail, but any metadata, such as location and subjects, can only be inferred.