Sam Ruby: AJAX Considered Harmful

Sam Ruby has done more careful and detailed analysis of the issues associated with http writes AJAX Considered Harmful...

First, if you thought you knew about http then go and read his presentation "Just" use HTTP and discover how much you don't know,

Second, I agree with Sam's thoughts. My personal assumption is that the Xml in AJAX also means REST and UTF-8 (as by default xml is unicode).

Therefore many of the examples are too trivial and misleading

• The XMLHttpRequest should be used for calls that need to be made to the server, not just for the sake of it.
• The calls should be message based. Not RPC.
• This should not move state to the server (violation of REST).

In a typical web based shop you would use XMLHttpRequest to GET stock levels. You would use it to submit the whole order (so that the basket can be redisplayed with the results of the order being placed, eg invoice number added, payment confirmation added). You would use it to do a GET to lookup product details, or to lookup the address.

For me the key issue with http pages is not the ability to submit them in little bits (because then your server has to keep accepting incomplete stuff that may never be completed) but the ability to dynamically lookup related data. All those lookups will already exist in your REST interface (GET product detail, GET product list, GET address etc).

So a key step in getting AJAX to work sensibly and securely for the long term is to make sure all the messages over the wire make business sense on their own. The web front end then becomes the presentation of those standard messages and AJAX improves that experience.

Comments

[Sam Ruby]

I'd argue that the encoding of the URI and encoding of the content are orthogonal.

Thought experiment: issuing two separate HTTP GETs against a URI can return differing results. If these two results differ in the encoding (via the Content-Type charset and/or the encoding in the XML prolog), should the way the URI itself is interpreted change?

[DaveW]

Hi Sam, Welcome.

a) I see what you mean about encoding of the URI and content. But isn't it just less confusing and therefore likely to be better practice to keep them the same - easy if you use utf-8 for both?

b) Again, yes you can use a different charset/encoding for the same uri, but why would you want to try to confuse your users by doing so? I guess if nothing else has changed the data between the two GET operations then you have to assume that when converted to a common encoding the two are identical - therefore the uri does not be interpreted differently.

I guess the answer to both is that the specifications do not currently enforce much in these areas, but sensible good practice (now your research has pointed out the issues) will keep things as simple as possible (ie use a single charset/encoding throughout an application/namespace).

Thanks

[Sam Ruby]

I do agree that adopting utf-8 throughout is a good idea.

A number of issues arise, however. First is that applications tend to be layered, with some layers implemented in libraries and independent of others.

A more problematic issue, however, is that AJAX applications -- almost by definition -- tend to be implemented in the context of HTML. The default encoding for HTML is iso-8859-1. It requires an overt action to declare your HTML pages as utf-8, and potentially a bit of breakage to your existing application and/or interpretation of data you may have stored in pre-existing databases.

[DaveW]

Sam,

You are, of course, correct. The real world is much more complicated that my simple answer indicated. However, we may be approaching from different directions. Your detailed analysis shows the extent of the problems with the current situation. I am trying to get it sorted (at least in my own mind) for a clean sheet application so that I have a target to aim for.

In my minds eye a clean new application (eg something like basecamp) would specify utf-8 encoding everywhere, it would be there at all levels. Any existing code to be connected would have to provide its own utf-8 translation layer (maybe using its own REST based service) so that the new app only sees utf-8. It would set utf-8 for all html pages.

Part of my thinking is that I see AJAX as just one user interface on top of a REST application server. It seems to me a mistake to therefore tie the application server to html, it should be xml (utf-8) over http (with utf-8 uri's). I don't like the techniques that use AJAX to collect the data in javascript formats from the server. It seems to me that this is premature performance optimisation for most applications and it means you end up writing multiple server interfaces (XML, Javascript...).

The challenge is can we use your detailed analysis to come up with a definitive description of the right way to do a new application and therefore something that can be used to plan a migration for existing applications ie we need to get the destination settled.