The Developers who have tried their hand at Web 2.0 AJAX, that I have spoken to, have almost without exception reported to me their journey through states of both joy, frustration, and concern around the use of that wonderful tool the XmlHTTPRequest.

The joy starts early on – “You mean it is that easy to get data from a server and dynamically insert it in to my web page without doing a refresh!“.

Rapidly drops to frustration – “You mean to say that I can only get data from the server from whence the page came “.

Moves in to creative mode – “If I create this little php script as a proxy on my server, my requests can see the world!“.

Followed by a worrying – “I wonder if my server will cope with the proxy load, what if its address becomes public knowledge?“.

Then comes the blinding light of JSON – “Absolutely magic! In a script tag I can insert a call to a JSON service anywhere without any of these Cross-Domain scripting issues to worry about“.

Finally the question of trust occurs – “This JSON stuff being injected in to the browser has full access to everything – do I trust the people that coded the service to only do what they say they were going to do, or will the viewers of my page become unwitting accomplices in a distributed denial of service attack?“.

On the final point, trust is an issue of who you get your service from. Users of the JSON versions of the Talis Platform APIs can rest assured that our services will only do what we say they will. So there! – problem solved. Well it is until some high profile instance of a very useful JSON delivered service is found to be a front for a password capturing scam – then see all and any trust, for all and any JSON service, dissolve like mist on a hot summer’s morning.

So in summary, although useful XmlHTTPRequest it is too restrictive to be really useful in orchestrating cross-domain web services together in the browser client; Although using JSON in a script tag is powerful and bypasses the limitations of XmlHTTPRequest, it is not widely supported and where it is can I trust it.

Greater minds than mine have been thinking about this. Jeff BezosBarr reports a lunchtime conversation with Peter Nixey of Web Kitchen around this subject. Peter in his posting Why XHR should become opt-in cross-domain relates the tail, of how the owner of a fictitious pub is having issues with his local council, to highlight what I have been describing.

Paul goes on to propose a solution to the XmlHTTPRequest cross-domain restriction problem, by allowing servers to opt-in to receiving cross-domain requests and then informing the browser of that opt-in with a new HTTP header.

I think this idea has much going for it. What do you think? Peter is asking for feedback. Let him know what you think.

Maybe this is something that the W3C Web APIs Working Group should consider for inclusion in to their Draft XMLHttpRequest Specification.

Update:
My thanks to my colleague Ian Davis, a member of our team who is involved with the W3C Web APIs Working Group. He has pointed me at a proposal for a cross-site XMLHttpRequest, which starts an interesting conversation on the Working Group mailing list.

Technorati Tags: Web 2.0, AJAX, XmlHttpRequest, W3C