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.
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.
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.