This week I was doing some work on a crossdomain JSON request. This was a pitty, because I had in mind, Ajax requests could be made between subdomains, but that wasn’t the case, therefore I had to come up with a solution.
Solution 1: Server-side proxy
One option we had, was a server-side proxy, but I didn’t like this solution. If you are proxying your crossdomain request through a webserver that has to handle a lot of requests per second, these requests can block other requests, because proxying is always a slow process.
Solution 2: JSONP
Then there is the JSONP method, which includes a script on the fly in the browser and this script is then evaluated. The problem however with this approach is that your JSON resources have to be rewritten as a evaluation. This evaluation is then executed and your JSON loaded in a variable.
Instead of:
{"somejsonobject":1}
you have to write:
var jsonobject = {"somejsonobject":1};
someCallback(jsonobject);
This is not very clean, because you have to decide in your remote JSON file what the variable will be named. JSONP is a method in which you give a variable and callback in the url and then the JSON will be rewritten. This solution is just not the right way, as we programmers all know why it is better to isolate logic from real data.
Solution 3: Crossdomain through flash
Then I looked at another solution that does crossdomain Ajax requests through a flash proxy. These solutions all gave a lot of problems, cause the encoding of characters was not handled properly by the Flash ExternalInterface compononent, which sended the JSON string it received to Javascript.
Solution 4: Parsing the JSON by flash
I then tried to make a solution myself that doesn’t send JSON string to Javascript, but (thanks for the idea Gert-Jan) sends the objects to Javascript. So the JSON is parsed into an object at the Actionscript side and it now all works. The project is opensourced under a MIT license and called: JSONCrossdomainRequest. It is a js file which includes a swf file in your page that can handle the requests. Please come over to GitHub and read more about how to install and use this project. The Actionscript project is also included. Good luck if you are going to use it and if you have any modifications let me know, it is a work in progress and we appreciate any help!
Project location:
http://github.com/japetheape/jsoncrossdomainrequest/tree/master
Tags: Ajax, crossdomain, json, request
Tim Knip's profile
December 6th, 2008 at 2:23 am
You should check out flXHR here: http://flxhr.flensed.com
It’s a fully XHR-API compliant drop-in replacement for native XHR (including JSON request/responses) that utilizes an invisible SWF for the communication layer. The wrapping javascript implements an identical API to the native XHR object, so it’s easily used in place of native XHR, including easy integration with major JS frameworks, but with cross-domain communication ability.
And btw, on the specific topic of the encodings through externalinterface related to JSON… I ran into these same hiccups with earlier versions of flXHR but they’ve now been fully addressed and flXHR is able to pass JSON bi-directionally just fine.
December 6th, 2008 at 2:49 am
One more note… Just posted this article which discusses some of the newest features of the about-to-be-declared-stable 1.0 production release of the flensed (including flXHR) projects:
http://www.flensed.com/fresh/2008/12/changes-and-new-features-in-flensed-1-0/
December 9th, 2008 at 12:04 pm
@kyle simpsons: I tried that project also, but found there was to much overhead for us. I don’t want to load the entire flensed framework, for such a small thing.
December 9th, 2008 at 4:49 pm
Fair enough… there is “some” overhead… But the entire thing (now, with ‘1.0′ about to be released!), including the SWF’s, the JS, etc, weighs in at under 47k. I think that’s pretty fair and comparable, considering the large amount of functionality and robustness it provides, and compared to other big JS frameworks and such.
I’m glad to see your project uses SWFObject, but you don’t properly (as far as I can tell) expose one of its most important features — ExpressInstall (”XI”). The entire “CheckPlayer” part of flensed was actually conceived to wrap swfobject with an API which could better expose that functionality to dynamically embedding SWF situations.
Namely, swfobject assumes a SWF will *always* be visible and big enough to hold the XI downloader — but in your case, and mine, this is not at all true, as the SWF is 1×1 and hidden.
The problem is, without some robust support like XI, users with an older flash (a little more common), or no flash at all (rare) will be stuck, and won’t even particularly know why. So one of the big pluses that flensed/CheckPlayer will give is that it provides a slick way to help users know about the flash dependency and makes it as painless as possible for them to get it installed/upgraded.
————————
Also, just like with other JS frameworks… you “load the whole thing” for a small task, true, but you also get all the beauty of the “whole thing”, which makes other tasks, either now or later down the road, much easier, too. For instance, any SWF operations you may want to do, you get all of CheckPlayer which is like SWFObject on steroids for that, with tons of useful features like callbacks, timeouts, EI detection, etc. And with the flensedCore, you get really robust UA detection, some helpful things like event binding, etc.
So, you have the potential to save in other areas of your page code, by relying instead on stuff you get “for free” by using flensed.
I’m not trying to argue here… I think you have a perfectly valid viewpoint on the overhead. But I’d also encourage you to take another look at flensed/flXHR if it’s been a little while since you tried it… being that it was in alpha, and is now about to hit full 1.0 production readiness, there’s bound to be improvements now which possibly could sway your opinion a little bit.
Either way, good luck with this project, glad it’s working so well for you! (and thanks for having given flXHR a shot)
December 9th, 2008 at 8:13 pm
@kyle simpsons: We use frameworks all the time. We rely on a framework protoype, i guess you know it. It would really be overhead when using 2 frameworks. Well I think for a lot of people your project suits the needs. For us it didn’t. I’ll have a look at the expressinstall part, thank you for mentioning… good luck with flXHR!