Thursday, August 20th, 2009
jXHR: XHR API, JSON-P backend conduit
Category: Ajax
The Mullet: Business up front, party in the rear
Kyle has take the XHR API that we all know and…. wrap…. and married it with a JSON-P transport to make jXHR.
He tells us more:
I’ve put out a very simple little project called jXHR which does cross-domain Ajax via JSON-P calls (meaning, totally javascript based), but does so with an emulation of the native XHR API (“onreadystatechange”, “open”, “send”, etc). It also provides some basic error handling capabilities, which is something most JSON-P solutions don’t currently offer, at least not without complicated timers, etc.
The goal was to provide a simpler interface for making cross-domain Ajax calls with JSON-P, but in nearly the same way you make same-domain calls, by using the standard XHR API. Also, I wanted the solution to be framework independent for those who don’t or can’t use jQuery, Dojo, etc
Frameworks such as Dojo allow you to choose an transport independent of their API (e.g. iframe transport versus XHR).
Related Content:
For the record, that is NOT a picture of me. :) But funny picture nonetheless, Dion. :)
The main point of jXHR, besides putting the familiar and well-known XHR API wrapper on top of dynamic-script-tag JSON-P calls, was to provide the “onerror” error detection handler functionality.
If you set “onerror” handler, and your JSON-P call fails for some reason, then you’ll be immediately notified, rather than needing to do your own timer detection, etc.
Also, jXHR is less than 700 bytes when minified and gzip’d, so it’s really small and easy to use just about anywhere, including bookmarklets, cross-domain widgets, etc.
lol funny pic
so you are not using an iframe! you use script tag
BTW, in honor of Dion’s awesome picture to visualize my API, this project can now be located at:
http://mullet.xhr.me
http://mulletxhr.com
hehe awesome
I love mullet !
BTW, it seems that “internal_callback” variable is global…
good catch, thank you @checkca. Will fix ASAP.
I think this API would be interesting if its intent was to be a fallback API rather than a “similar syntax”. So if a browser supports the new standard, it uses that, but if it doesn’t, it uses JSONP, either way no manual toggling involved for the developer.
@stimpy77 — i think you’ve actually hit on exactly why I think that standardizing on the same API is important… so that it’s easy to swap in optional implementations depending on technical environment but without having to code more complex code that makes calls differently. When it’s the same (or nearly the same) API, it greatly simplifies that kind of usage. And that’s my goal, to provide more options for cross-domain Ajax, but without fragmenting the API into an unmanageable mess.
one problem for dynamic script loading is that you do not get XHR response.status from the server, so no way to check for 404 or 500. if you have an invalid url, you never get the publicAPI.onerror handler.
distinct from publicAPI.onerror, with HTML5 ( http://bit.ly/qb5GfU ; see item #14), you can define scriptElem.onerror for any type of error loading the script.
i added this mod to your script to handle invalid url errors:
after handleScriptLoad
// MOD: added handleScriptFail()
function handleScriptFail() {
if (!script_loaded) {
ThrowError(“Script failed to load ["+script_url+"], most probably due to an invalid URL or server error.”)
}
}
inside send:
// P4 MOD: added onerror
scriptElem.onerror = function() {
handleScriptFail.call(scriptElem);
};