The Facebook APIs, part 1: Openness vs the walled garden

As I noted in the first post of my new series on third party APIs, there has been an explosion in the number of web APIs available for our use.  We’re now in the thousands of publicly available APIs, and the number continues to rise so fast that it’s hard to keep up with what’s important and what isn’t.

I asked for your input on which APIs you’d like to see discussed (click here to fill out the very short survey if you haven’t already).  Readers have started to speak, and one obvious request that lines up well with PayPal’s push around Mobile + Social + Local (MoSoLo) is the Facebook platform and its APIs.

Here’s a brief history of Facebook’s developer efforts:

Facebook made their initial API launch in 2006.  These APIs were primarily meant to be used by developers to write applications running outside of Facebook that could tie into a limited set of Facebook data.  It was a start, but there was much to still be desired.  In 2007, they announced the Facebook Platform which allowed developers to write applications to run within Facebook’s site itself.  More access to Facebook data, but also much more closely tied into Facebook via their proprietary platform.  One step forward, two steps back.

After several years of inward-focused efforts and plenty of criticisms of its walled garden approach, Facebook appears to have finally drunk the open Web beverage.  Last spring they announced a major revision to their API set and approach.  They stated their intention to open up to external applications having robust access to Facebook data and features via their new social plugins, Open Graph protocol, and Facebook Graph API.  Click here to read an analysis of the 2010 launch from ProgrammableWeb.

Click here to read the rest of the PayPal X Developer Network post including a discussion of the key point of Facebook’s new approach. Also links to a bit.ly bundle of all the resources discussed in the post.