OpenIDJSON and Yahoo!’s JavaScript APIs
I had the pleasure yesterday of seeing Douglas Crockford speak about JSON, the ultra-simple data interchange format he has been promoting as an alternative to XML. JSON is a subset of JavaScript, based around that language’s array, string and object literal syntax.
As of today, JSON is supported as an alternative output format for nearly all of Yahoo!’s Web Service APIs. This is a Really Big Deal, because it makes Yahoo!’s APIs available to JavaScript running anywhere on the web without any of the normal problems caused by XMLHttpRequest’s cross domain security policy.
Like JSON itself, the workaround is simple. You can append two arguments to a Yahoo! REST Web Service call:
&output=json&callback=myFunction
The page returned by the service will look like this:
myFunction({ JSON data here });
You just need to define myFunction in your code and it will be called when the script is loaded. To make cross-domain requests, just dynamically create your script tags using the DOM:
var script = document.createElement('script');
script.type = 'text/javascript';
script.src = '...' + '&output=json&callback=myFunction';
document.getElementsByTagName('head')[0].appendChild(script);
In long running apps you’ll want to work out some kind of cleanup system to remove script tags from the DOM once they have been executed. More on this technique here.
It should be noted that del.icio.us has had APIs like this for a while.
Dustin Diaz - 16th December 2005 00:58 - #
This is one of those things where you smack yourself on the forehead and wonder how you never thought of it...
Jeremy Dunck - 16th December 2005 02:45 - #
John Wehr - 16th December 2005 04:43 - #
James - 16th December 2005 05:37 - #
"it makes Yahoo!'s APIs available to JavaScript running anywhere on the web without any of the normal problems caused by XMLHttpRequest's cross domain security policy"
I think JSON support is great, too. However, how does this allow a developer get around a browser's cross domain security policy? You still can't make cross domain XHR request from the browser... you'll still need a "proxy." Sorry, please explain.
Curious - 16th December 2005 17:29 - #
Eugene Lazutkin - 16th December 2005 17:42 - #
Bob Ippolito - 16th December 2005 18:00 - #
"ultra-simple data interchange format"
No, you are wrong. It is ultra-obtuse. JSON is only for developers who can swallow the almost deliberately obscure presentation that Crockford gives. Fine if the Web were elitist -- but it is not. Techniques and advances not understood and implemented by large numbers of adopters go into the dustbin quickly.
JSON will need support from people who both understand it and are willing to properly explain its advantages to others.
BrettBrett Merkey - 16th December 2005 19:16 - #
Scott Johnson - 16th December 2005 19:27 - #
.appendChild()).Shawn Brown - 16th December 2005 19:47 - #
Rich Manalang - 16th December 2005 20:48 - #
grumpY! - 16th December 2005 23:02 - #
Scott, while I agree Brett's tone was overly abrasive, Yahoo would very much like people to find value in their JSON impl.
Brett, if you've coded, I'm sure you're familiar with common literal conventions:
var number = 4; var string = "value";Javascript goes further by allowing its basic data structures (arrays and objects (aka dictionaries or hashes)) to be represented as literals:
var arr = [1, 2, "foo", "bar"]; var dict = {'keyToNumber':1, 'keyToString':'value'}Who cares? Well, among other areas where its useful, when interacting with a server, you need some common interchange format. Often, XML is used for this. In that case, you need an XML parser on the client, and you need to know how to traverse the DOM of that XML document.
JSON is more of an idea than a new format. JSON is just javascript. I'd give more clear examples, but Simon's XHTML filter makes me not want to spend the time escaping the XML brackets needed for the comparison. ;) But here's a pretty good writeup.
It's basically just a big dictionary of nested values. But this is useful because now, instead of taking a foreign format, parsing it, and using the XML DOM API to work with it, you (the javascript client) get back a javascript data structure.
Still not convinced? The Yahoo implementation goes a step further, because rather than you having to request a foreign URL (limited by same-source policy) over XHR, you can now just add a script tag with a src attribute set to the API URL. The response of that is a javascript which runs with local permissions, and calls back your handler function, passing in the dictionary for you do process.
Jeremy Dunck - 17th December 2005 17:35 - #
"Brett's tone was overly abrasive."
Yes, it is the tone I take at work. It is effective dealing with herds of managers who arbitrarily attempt to infuse their ignorance into the Web application development process, degrading the user experience and code maintainability. My tone gets their attention right quick.
Here, the ignorance is mine. Jeremy, I can readily see from the example link you gave (thanks!) some impressive results. Results but no explanation. Better than Crockford's abstractions with no explanation and no results -- but still unsatisfactory.
For most Web workers, the sources for JavaScript usage are creaky old. There are few books out that go into the new approaches. Here are two:
Clearly, these can be seen as only a beginning. JSON cannot possibly be used until both its purposes and its foundations are understood. The obstacles to that are still very great.
Brett
Brett Merkey - 18th December 2005 19:15 - #
I'm not sure why the linked article is a "problem" with Ajax - it seems instead to be a problem with applications that are basically client-side Javascript applications wanting to call external services without any server-side logic.
If you are using Ajax to do client-server applications, with javascript providing the UI experience and server-side code providing the business logic, then there is no problem. The client sends a XMLHttpRequest call to the server, the server calls the external service, manipulates the results as required (sanity checking, error handling, caching, filtering) and feeds a subset of the results back to the client asynchronously, and the client handles the rendering.
For Javascript-only apps, JSON embedding looks useful - but this is only a small subset of web apps.
Korny - 21st December 2005 01:24 - #
Here's what I don't understand. Every site that uses Google AdSense includes a script tag whose src points to Google. That looks to me like cross-domain scripting (albeit not with XmlHttpRequest).
Some questions (all related to cross-domain, i.e. so people can embed as little code as possible in their pages to call out to my new service):
1. What does JSON add to the picture? (I understand the XML vs. JSON issues, just not how JSON simplifies cross-domain.)
2. Under what cross-domain circumstances is it useful to construct a script and then appendChild(script) rather than just include the script directly (as with Google AdSense)?
3. Since my main goal is to stuff some HTML into a page (like I could do with XmlHttpRequest + innerHTML if that worked cross-domain), how does JSON help? It looks like a great way to encode arrays and such but I don't understand how to encapsulate a few K of HTML.
I don't mind paying for some consulting time to help tackle these, though I do think they're of general interest. Links are welcome, preferably to sample code rather than just descriptions (which often assume too much).
(FWIW, I've written code in several languages but I'm a JavaScript beginner. So I may well be missing something "obvious".)
Scott Lawton - 23rd December 2005 15:26 - #
OK, after more research and testing, I can now provide some partial answers to my earlier questions:
1. I'm pretty sure JSON doesn't help cross-domain scripting per se; it has the same benefits (and tradeoffs) for cross-domain and same-domain. Yahoo's APIs are just one place where those benefits are now available.
2. if you want something to happen when the page loads, it's fine to just include the script directly. If you want something to happen afterwards (e.g. in response to user input), the only (I think) way to call out to a server (e.g. Yahoo) other than the page that served the main page (e.g. your server) is to construct the script on the fly. The browser will run the script when it gets added.
3. JSON probably doesn't help if the goal is to insert some HTML; it's better for constructing the HTML on the client using raw data returned from the server. To encapsulate HTML (e.g. for document.write or the more flexible document.getElementById('my_target').innerHTML=), encode single quotes AND newlines by prefixing with backslash.
The url sent to the server in the src= can be anything; the data sent back must be a valid javascript (e.g. something that could, for testing, be pasted between script.../script tags. And, if the URL stays the same across multiple calls, it might be cached.
Scott Lawton - 30th December 2005 11:22 - #
I don't understand why you would have to traverse the an XML DOM tree when XSL is so easy to use. At work I developed a web portal for around 56,000 users that uses XML and XSLT to create the web pages. It is just not that difficult to use XSL to transform XML into HTML or XHTML.
I do like the cross domain capability of JSON which allows a developer to make the client do the work instead of the server which is what I do now.
Tanny O'Haley - 1st January 2006 01:32 - #
Does anyone care that Crockford's too-clever-by-half JSON license is not open source? is the epitome of a violation of point 6 of the open source definition (no discrimination against fields of endeavour). These kinds of clever jokes in licenses are about as funny as jokes about bombs in airports.
Mark - 1st January 2006 03:03 - #
JSON License?
WTF is a JSON License?
JSON is just a subset of javascript object literals. It comes with javascript, it is part of javascript, IT IS JAVASCRIPT!
Who needs a license to use Javascript?
He didn't invent Javascript. He's been promoting JSON but he should not try to make himself look like he invented JSON
Puzzled - 2nd January 2006 04:47 - #
Simon Willison - 2nd January 2006 10:18 - #
Crockford's NOT OPEN SOURCE license appears to cover implementations in ActionScript, C#, Java, JavaScript, and REBOL. It also appears to cover the JSON checker, and may cover the specification itself and all of the examples contained therein.
I claim that this is a serious matter. If someone with deep pockets (say, your employer, Yahoo) were using any of these implementations and Crockford decided that you were using it for Evil and not for Good (whatever the hell that means), you could have a very unfunny legal battle on your hands.
I really, really, really wish I were kidding. Go ask my employer whether they think licensing legal battles are funny.
Mark - 3rd January 2006 05:07 - #
Douglas Crockford - 30th January 2006 20:46 - #
Rxbbx - 9th February 2006 15:45 - #
Douglas: we are all in agreement that your license is a "slightly modified MIT license"; it's the modification that I'm talking about! (And BTW, the very fact that you need to produce "one-off" licenses should be your first clue that you're doing something wrong.)
But seriously, thanks for clarifying why I will never touch JSON with a ten-foot pole. Statements like "If someone is unable to assert that they are not using it for Evil [whatever that means], then I don't want them using my software" are just flabbergasting. And then to assert that it's "just" a slightly modified MIT license, as if "close enough" counted for anything... unbelievable. Just a stunning display of sociopathy.
Simon, you seriously need to talk to Yahoo's legal department, and I mean NOW, before Yahoo does anything else with this technology.
Mark - 10th February 2006 16:52 - #
Linus Thorvalds - 12th February 2006 07:33 - #
Jim - 16th March 2006 01:48 - #
Clearly Mark is suffering from a guilty conscious...
Surely he is bent upon evil intent...
and that is why this clause bothers him so.
Personally, I had always thought about putting an additional clause in the license (for my programs) that the use must be "non-fattening"...
;-)
Erik - 17th April 2006 11:09 - #
whoopdeedoo - 10th June 2006 06:20 - #
I learned about the existence of JSON about 40 minutes ago, so trust me that I'm not trying to take sides here...but, when is the JSON community going to start to run into some of the same problems that the XML community has spent years solving?
One example: the use of namespaces to disambiguate tags (or "names" in JSON-speak). I take this JSON doc as an example:
cubism.js
What is the true meaning of "link" in this doc: does it have to be a URL? or can "link" mean the connection between my computer and the internet? While there are multiple potential meanings of "names", there are multiple possible processing paths.
There are of course many applications that never run into this kind of problem - and yet namespaces have become a crucial component of the XML world. Will JSON not run into this as well?
- ds
dan - 1st August 2006 10:55 - #
jam - 17th November 2006 01:09 - #