<p>Bob Ippolito recently proposed “JSONP” as a standard for grabbing JSON from external domains. It’s about a cleaner way to get data objects (and other things) from the external domain.

With On-Demand Javascript, you specify a URL as the source of a new script tag and the browser evaluates the script sitting at that location. Thus, the script can’t *just* be a JSON expression, because it will have no effect. If the script is:

7

the JSON expression “7″ will be evaluated and so what? No change. What needs to happen is a variable assignment:

score=7

After evaluating that remote script, our own script now has a “score” variable with the value we wanted. The problem is that the remote script shouldn’t be choosing variable names for us.

Another problem is notification. Since remote scripts are sometimes loaded asynchronously, we might like the remote script to try notifying something in our own script to tell us it’s finished:

if (self.onScoreLoaded) { onScoreLoaded(); }

Or maybe we’d prefer the event handler to be passed the value:

if (self.onScoreLoaded) { onScoreLoaded(7); }

The point is, there’s a lot of things we might want the remote script to do. And many times, the remote script is supposed to be used by lots of clients, such as the Delicious API example in Bob’s post. Whatever behaviour the remote script performs, it’s not going to satisfy every client.

So this is where JSON with Padding comes in. Bob wants to make these remote scripts more flexible, so a client can control how they work. Under the proposal, our script would simply tell the remote script what to output before the data object. So we call the script with a prepend var:

example.com?jsonp=onScoreLoaded

And the script would then output jsonp + "(" + resultJSON + ")". In this case:

onScoreLoaded(7)

JSONP is a simple but powerful idea. One minor question – why only prepend? Maybe some clients would prefer to append as well. You could theoretically handle all cases with a prepend, but append might just make life easier. That little detail aside, JSONP is well worth considering if you’re offering a JSON-based web service.

Why NOT only prepend? There’s no reason to append. The more detail there is to the spec, the more likely somebody is going to implement it incorrectly on one side or the other. This is the simplest thing that could possibly work (for all use cases).

Bob, agree that appending adds no new functionality, and in a protocol of this nature, that’s a pretty good argument to KISS and stick with only prepending.

The main argument for append is that I think we’ll see different idioms evolve in the whole area of remote scripting and JSON; adding a tiny bit more functionality in append just seems like it might encourage more creative uses to evolve.

I’m reluctant to mention specific examples, because my main point is that best practices will only come from real use. But one example would be appending a property value (ie. json + “.height”) or an array index (json + “[5]“).

“Your page is still toast if the remote host decides to inject malicious code instead of JSON data. However, if implemented, it’d save a lot of developers some time and allow for generic abstractions, tutorials, and documentation to be built.”

I’ll take extra time over toasted pages any day of the week.

This idea was floated in the JSON-PHP group a few months back, and I felt pretty strongly that it was a bad one. Two reasons: 1) JSON isn’t just for javascript, so adding syntax that only makes sense in javascript narrows its utility. Even the parentheses break Doug’s simple spec. 2) Executing arbitrary responses from the server seems like a recipe for disaster. From this point of view, I’m not altogether satisfied with the simple “eval()” method for handling JSON responses.

There’s a lot of room for abuse in networked applications, and the excitement about API’s, XHR and JSON could lead to a serious Outlook-style problem for javascript apps in the near future.

I see no reason to do any work on the server for this (even just prepending a small string). It can be handled on the client entirely – in which case it is simply defining a callback function, which most AJAX code already does.

No. JSONP is an optional extension, if you don’t specify the jsonp query argument, then you get a normal JSON document. No compatibility is lost, specs aren’t broken.

eval() is perfectly safe for normal XMLHttpRequest. After all, it’s the same host you downloaded the JavaScript code from! If you can taint the JSON response, you surely could’ve tainted the code making it. The remote host case is another story, but *you don’t have a choice*.

[...] On a post I made a few days back I proposed a way to do cross domain AJaX using XML rather than the commonly used JSON. It is essentially an extension of the idea of JSONP (JSON with Padding). Since I generally find myself working with XML more often than JSON I decided to create the equivalent for XML based applications. I have not extensively tested it but did try it on IE6 and FF1.5 on Win2K server. [...]

JSONP is an interesting concept, though I’ve encountered it just now, in 2011.

However, I still can’t think of a real-world example of it. Should we use it for example for authentication purposes where the authentication URL sends back a JSON object of the logged-in user as JSONP? Can you add some real-world examples AJAXIAN?