258 JSONP APIs: Get Your JSON Response Anywhere

Adam DuVander
Oct. 07 2011, 09:22AM EDT

JSON is popular, at least when it comes to API data formats. Of the new APIs we added to our directory, one in five supports only JSON. But how many support JSONP, which allows developers to load data directly on the client side no matter the originating server? There are 258 JSONP APIs out of a possible 1,724 JSON APIs. That's only 15% that support an approach many developers will want to use.

First, let's take a step back and look at why JSONP is important. The reason is tied very closely to why JSON is popular in the first place. JSON stands for JavaScript Object Notation. It can be directly translated into a JavaScript object. No parsing necessary, just get at the data. With web apps becoming more JavaScript-dependent, it's clear JSON is the developer's choice.

JSONP becomes important when developers want to access on the client machine data that exists outside of the website the user is visiting. Since that's precisely the use case of APIs, it's surprising to see so many support JSON and so few support JSONP. For a select few there could be a good reason, such as keeping API keys or signatures secret. But for the vast majority of those 1,466 JSON APIs that don't support JSONP, why not support JSONP?

JSONP simply wraps the response in a function call named by the developer. The P stands for "padding," where the provider needs only pad the results with a bit more information. Supporting JSONP is a cinch.

An up-and-coming alternative to JSONP is CORS, which stands for Cross-Origin Resource Sharing. It's a way for an API provider to tell browsers to go ahead and return the data anywhere. There are also a few other options, such as cross-domain files for Flash and Silverlight. Apigee has a post highlighting the many options with its recommendation that providers should implement all options to gain the widest developer adoption.

And that's probably the biggest shocker of JSONP adoption. API providers try many things to court developers to their platforms. Supporting JSON is one of those things many try, because they know developers want JSON. But then, most providers stop there, not supporting the few additional characters needed to become even more useful for developers.

Some cite security concerns over JSONP, as it can pass on script injections. And since JSONP has simply been a pattern that developers and providers have used, there hasn't been much standardization. One site calls it an unsafe and hacky approach.

Security concerns shouldn't be belittled, but it's unlikely that is the only reason so many haven't supported it. Further, by bringing standards to JSON, will that negate some of the simplicity that has attracted developers to it in the first place? Of course, security is by its very nature not simple.

For examples and other ways to run APIs client-side, be sure to check out Pamela Fox's presentation Client-side APIs: How, What and Why.

Thanks to Lead Developer Evan Muehlhausen, who ran searches for callback and jsonp on every JSON API and Content Editor Jada Maxwell who parsed all the potential matches.

Adam DuVander Hi! I'm Developer Communications Director for SendGrid and former Executive Editor of ProgrammableWeb. I currently serve as a Contributing Editor. If you have API news, or are interested in writing for ProgrammableWeb, please contact editor@programmableweb.com Though I'm a fan of anything API-related, my particular interest is in mapping. I've published a how-to book, Map Scripting 101, to get anyone started making maps on websites. In a not-so-distant past life I wrote for Wired and Webmonkey.

Comments

Comments(4)

User HTML

  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

I would call that a transform, as one must transform the data from the everybody hostile XML tree model to Javascript friendly lists and tables.

"Security concerns shouldn’t be belittled, but it’s unlikely that is the only reason so many haven’t supported it." It's an API that says "here, run this code" which is hardly an API at all. That security is not blocking adoption requires some evidence. I think you should address that deeper to have a more meaningful article.

I'm not sure why bringing standards to JSON would slow adoption. Javascript has benefited greatly from standardization, not being the incompatible mess it once was. So has JSON, standardizing it as an RFC, allowing it to be parsed by other languages and without security concern. JSONP cannot be parsed securely and it cannot be parsed by other languages.

"No parsing necessary, just get at the data" is a bit glib. Unless the JSON is coming from a known and very, very trusted source, you still need to parse it. Evaling it as Javascript code risks attack.

[...] 258 JSONP APIs: Get Your JSON Response Anywhere JSON is popular, at least when it comes to API data formats. Of the new APIs we added to our directory, one in five supports only JSON. But how many support JSONP, which allows developers to load data directly on the client side no matter the &#8230; Read more on ProgrammableWeb (blog) [...]