ecmanaut: JSONP: Why? How?

2006-01-31

JSONP: Why? How?

Codedread took me up on a few points worth discussion in relation to my previous post about JSONP:

Isn't the feed consumer very susceptible to incompatible changes in the source feed?

Yes; naming issues are the same for JSON as for any XML dialect; the day your data provider breaks backwards compatibility with the format they previously committed to, your application breaks. It can be argued that widely adopted schemas such as RSS and ATOM are safer bets to write code for, but in my opinion it's a bit of a moot point. As soon as you use somebody else's data, you are at their mercy of still making it available to you in whatever format they picked. Content providers are still kings of their reign. When Del.icio.us has downtime (and don't care enough about their JSON feed consumers to degrade gracefully, still providing a valid, though empty, JSON feed) your application breaks.

How do you ensure that the JSONP feeds don’t embed bad code with side effects you did not opt in on?

If you live solely client side, having just the provisions of the browser sandbox in unprivileged mode, as is the common case when JSONP is interesting at all: you can't. You are at the mercy of your feed provider's better judgement. Should you discover that they break the "contract" in passing code rather than data your way, wreak havoc and give them the devastating publicity they deserve. Pick your feed with the same attention to the trustworthiness of the source as when you pick your food. Don't eat it if you fear poisoned food. Or feeds.

If you can't trust your feed source not to send code with unwanted side effects, and you have elevated privileges (either from being a signed script, or perhaps because you are a Greasemonkey user script or similar), so you can fetch content by way of XMLHttpRequest (side-stepping the same origin policy), you can use a JSON parser rather than eval() to process the feed. The JSON site provides a JSON parser written in javascript.

Otherwise you would have to use some server side script to process and cleanse the feed first. In which case your choice of picking up just any feed at all and reformatting it as JSONP would be the solution most close at hand. Of course this is always an option open to you regardless of the original format (RSS, Atom or anything you know how to read) if you have a server side base of operations where you can cook your own JSONP. Making a generic XML to JSONP converter, as Jeff suggests, is of course a neat idea.

How do you include JSONP feeds dynamically into a web page?

Point a script tag at the feed. If you plan on spawning off multiple JSONP requests throughout the lifetime of your page, clean up too, removing the script tag you added for the request, for instance from the callback you get when the script has loaded.

What about XML?

What you do with XML, you should probably keep doing with XML, as there is that much of a larger tool base available for leveraging it. JSONP isn't here to replace XML in any way, it's strength is solely in overcoming the same origin policy of the browser security model. (Sure, the markup overhead of JSONP is roughly 50% less than that of XML, and XML formats are typically designed in a bulkier fashion than typical JSON formats in prevalent use today, but neither is really much of an argument for most practical purposes.)

Why should you adopt JSONP too?

The way I see it, providing JSONP feeds for external consumption is really only interesting when you invite the wide public to innovate around your data, client side, unaided by any kind of server side resources on their part. If you don't, there is not much point in doing this at all. Doing JSONP is just lowering the bar as far as you can possibly go, in inviting others to use your service programmatically.

It's comparable with providing a dynamic image meant to sit on a web page, or a really small web page component meant to go in an iframe of its own. The striking difference is that your data becomes available to programmatic leverage, which neither the image nor iframe does due to the browser security model (not counting the provions on offer for partially hiding them by way of CSS).

What is the guaranteed payoff with making a JSONP feed?

None. If your users don't want to use your data, they won't. Nor will they, if they don't know it's there, or how to make use of it. JSONP isn't widely known yet, and javascript has much bad heritage of being a language people cut and paste from web sites to get nifty annoying page effects going on their web pages. To this public, a JSONP feed is useless. It's for the growing community of "Web 2.0 programmers", to use a nasty but understandable name for them, that your JSONP feed will be useful. And you get no guarantees that anyone will use it for anything either; your data might not be interesting, or you might smell like the kind of shady person that would salt their JSONP feed with nasty side effects, stifling people that would otherwise have considered building something with your data.

The only firm guarantee is that nobody will use a feed you don't provide.

All of the above is the price we pay to use data we don't produce ourselves, and for overcoming the same origin browser policy security model, which is the very heart of the JSONP idea. Nothing has changed in this field since the millennium (except we have now got a name for a best practices approach for the behaviour/design pattern), though the WHAT WG are churning away at better hopes for the future. Until anything concrete comes out of that, we are stuck with JSONP for things like this, though. Be sure to make the best of it.

Categories:

Codedread took me up on a few points worth discussion in relation to my previous post about JSONP:

Isn't the feed consumer very susceptible to incompatible changes in the source feed?

Yes; naming issues are the same for JSON as for any XML dialect; the day your data provider breaks backwards compatibility with the format they previously committed to, your application breaks. It can be argued that widely adopted schemas such as RSS and ATOM are safer bets to write code for, but in my opinion it's a bit of a moot point. As soon as you use somebody else's data, you are at their mercy of still making it available to you in whatever format they picked. Content providers are still kings of their reign. When Del.icio.us has downtime (and don't care enough about their JSON feed consumers to degrade gracefully, still providing a valid, though empty, JSON feed) your application breaks.

How do you ensure that the JSONP feeds don’t embed bad code with side effects you did not opt in on?

If you live solely client side, having just the provisions of the browser sandbox in unprivileged mode, as is the common case when JSONP is interesting at all: you can't. You are at the mercy of your feed provider's better judgement. Should you discover that they break the "contract" in passing code rather than data your way, wreak havoc and give them the devastating publicity they deserve. Pick your feed with the same attention to the trustworthiness of the source as when you pick your food. Don't eat it if you fear poisoned food. Or feeds.

If you can't trust your feed source not to send code with unwanted side effects, and you have elevated privileges (either from being a signed script, or perhaps because you are a Greasemonkey user script or similar), so you can fetch content by way of XMLHttpRequest (side-stepping the same origin policy), you can use a JSON parser rather than eval() to process the feed. The JSON site provides a JSON parser written in javascript.

Otherwise you would have to use some server side script to process and cleanse the feed first. In which case your choice of picking up just any feed at all and reformatting it as JSONP would be the solution most close at hand. Of course this is always an option open to you regardless of the original format (RSS, Atom or anything you know how to read) if you have a server side base of operations where you can cook your own JSONP. Making a generic XML to JSONP converter, as Jeff suggests, is of course a neat idea.

How do you include JSONP feeds dynamically into a web page?

Point a script tag at the feed. If you plan on spawning off multiple JSONP requests throughout the lifetime of your page, clean up too, removing the script tag you added for the request, for instance from the callback you get when the script has loaded.

What about XML?

What you do with XML, you should probably keep doing with XML, as there is that much of a larger tool base available for leveraging it. JSONP isn't here to replace XML in any way, it's strength is solely in overcoming the same origin policy of the browser security model. (Sure, the markup overhead of JSONP is roughly 50% less than that of XML, and XML formats are typically designed in a bulkier fashion than typical JSON formats in prevalent use today, but neither is really much of an argument for most practical purposes.)

Why should you adopt JSONP too?

The way I see it, providing JSONP feeds for external consumption is really only interesting when you invite the wide public to innovate around your data, client side, unaided by any kind of server side resources on their part. If you don't, there is not much point in doing this at all. Doing JSONP is just lowering the bar as far as you can possibly go, in inviting others to use your service programmatically.

It's comparable with providing a dynamic image meant to sit on a web page, or a really small web page component meant to go in an iframe of its own. The striking difference is that your data becomes available to programmatic leverage, which neither the image nor iframe does due to the browser security model (not counting the provions on offer for partially hiding them by way of CSS).

What is the guaranteed payoff with making a JSONP feed?

None. If your users don't want to use your data, they won't. Nor will they, if they don't know it's there, or how to make use of it. JSONP isn't widely known yet, and javascript has much bad heritage of being a language people cut and paste from web sites to get nifty annoying page effects going on their web pages. To this public, a JSONP feed is useless. It's for the growing community of "Web 2.0 programmers", to use a nasty but understandable name for them, that your JSONP feed will be useful. And you get no guarantees that anyone will use it for anything either; your data might not be interesting, or you might smell like the kind of shady person that would salt their JSONP feed with nasty side effects, stifling people that would otherwise have considered building something with your data.

The only firm guarantee is that nobody will use a feed you don't provide.

Categories: