Where RSS and Atom are well defined XML formats, JSON is more similar to XML, in just being a data encoding, and a very light-weight one, at that. Besides being very light-weight, JSON is also the native javascript format for writing object literals, hence the name "JavaScript Object Notation". And since the native scripting language of web pages is javascript, it should come as no surprise that you open up your data for user innovation by providing it in JSONP form. The P stands for "with Padding", and it only defines a very basic URL calling convention for allowing a remote web page to supply your feed generator with a query parameter
callback to encapsulate the generated feed in such a way as to make it usable for the page that requested it.So, as neither JSON nor JSONP specifies anything about the actual feed content format for data, you are encouraged to think up something for yourself whichever way you please, and remain consistent with yourself, as, if and when you might opt to upgrade the feeds you provide with more data. I'll pick GeoURL for an example here, which has an RSS feed that contains this item structure:
<item rdf:about="http://ecmanaut.blogspot.com/">Formatted as JSON, paying attention to making the data as useful as possible to an application as possible rather than formatting it for human consumption, it might end up looking like this instead:
<title>ecmanaut</title>
<link>http://ecmanaut.blogspot.com/</link>
<description>Near Linköping.</description>
<geo:lat>58.415294</geo:lat>
<geo:long>15.602978</geo:long>
<geourl:longitude>15.602978</geourl:longitude>
<geourl:latitude>58.415294</geourl:latitude>
</item>
{"title":"ecmanaut", "url":"http://ecmanaut.blogspot.com/", "cityname":"Linköping", "lat":"58.415294", "long":"15.602978"}I substituted the "description" field for a "cityname" entry for the name of the closest city. You can of course easily improve on this with other relevant data too, for instance, why not add "citylat" and "citylong" values while at it? Or, you might nest it stylishly in another object, as
{"title":"ecmanaut", "url":"http://ecmanaut.blogspot.com/", "city":{"name":"Linköping", "lat":"58.4166667", "long":"15.6166667"}, "lat":"58.415294", "long":"15.602978"}which would allow an application to access the data as
city.name, city.lat and city.long. (Or, given that long is a reserved word in javascript, perhaps more safely as city["long"]. Hence the common practice of naming longitudes lng in javascript code instead.)The spaces in the above examples are purely optional, and were only added here for easy reading. Whether to provide latitudes as strings, as above, or numeric literals (dropping the quotes) is of course up to you, but I deliberately chose the string representation above, as that leaves it up to the application whether to treat them as numbers to do math on or text data to do some kind of visual or URL formatting operations on. Using floats instead would have lost precision information, as decimal and rational numbers are represented by IEEE floating point numbers in javascript, meaning that there would be no telling the difference between 0.0 and 0.000, or different numbers with many figures, where the differences appears only near the end. Opting to use strings, your consumers can pick either; the difference is just another
parseFloat() call at their end.Anyway, you might ask yourself what good providing JSONP feeds does you, as a service and feed provider. At least you should, as it's a very good question. A JSONP feed will (technically) allow any web page anywhere on the web to use your data in any way it pleases. This may be what you want when you provide a blogging service you want to popularize, a user customizable guest book with built-in feed support et cetera, and it may be quite contrary to what you want for information whose reach you want to be in greater control of yourself. (Of course, you can technically limit the scope of a feed using referrer detection tricks just as you can to avoid image hot linking, and it naturally also has the same issues with browsers and proxies set up to provide some amount of browsing anonymization.)
The real value with JSONP distribution is this: user innovation. It allows a third party to very easily leverage the functionality your tool or service provides, mash it up with other tools or services, and build really great things in general; things you probably never would have thought of yourself, or if you did, at least not had the ambition of doing of your own accord. And definitely not at no investment cost to you.
Opening up your data allows anyone and everyone on the web to do those things for you, should they want to. Ask for a link back from their cool applications, and you have a sudden generator of incoming traffic and visitors that builds on its own as others innovate around your service. This is pretty much what the fluffy word Web 2.0 is all about, by the way, at least to me. Data transcending barriers between sites and applications. Users playing an active role on the web rather than consuming a web made by others to solve problems dictated by slowly rusting business models.
The visitor map on top of my blog is just one example of what has been (and hence can be) made with JSONP; the feed provider of coordinates for recent visitors is provided by GVisit, and the naked feed is combined with Google Maps using the public Google Maps API. Yes, that rather boring text data becomes the pretty eye candy that lets us boggle at the many interesting places from which people drop by for a casual read here.
Assuming GeoURL provided JSONP feeds too, I could have asked it for blogs and web pages created near places where recent visitors of mine reside, and perhaps feature a rolling feed of pages made in their surroundings, as my visitor map zooms around the corners of the globe, tracking my erratic visitor patterns as curiosity drives eyes this way from all over the world. Add to that some optional topic tags data to each URL from that service, and a way of filtering the feed on the same tags, and it might even be made an opt-in self moderated list of links to peers of mine around the world for other blogs on topics such as javascript, blog and web technology, or what have you.
As you see, it's actually rather easy to come up with good web services that interesting applications could be built around in an open community fashion, this way, and JSONP is the brilliantly no investment, user interest driven way of doing it. It's trivial to make a JSONP feed, it's easy to leverage it into applications of your own as a web programmer, and the possibilities they open up for are nothing short of astounding.
I warmly recommend following Yahoo's lead here, but don't squash the
callback parameter, the way they do; put it in the feed verbatim, so the applications developer won't have to jump through needless hoops to put your feed to good use making tomorrow's killer applications.