I tried to integrate my site, Scribophile, with FB a few years ago when the API was still relatively new. The idea was to give the user the option of adding a wall post to their profile when they posted writing to the site.<p>The API had the exact same problems then... unanswered questions, confusing documentation, complex code examples. Something that seemed so simple--post a link to someone's wall, with their permission--turned into a multi-day codefest. But I finally got it working!<p>Until one day a few months later, when the API changed without warning. And that's what I think the biggest problem with the FB API is... they (at least back in the day) change it constantly, without much warning, and don't update documentation in a sane way. It's impossible to build once and forget.<p>I finally got a complaint from a user one day that the FB integration wasn't working. When I went in to check the code, I found that FB had almost completely changed their JS libraries and made significant API changes. Instead of going through that hell again, I just removed the feature.
I should say that I've been lurking on HN for quite some time and that this is my first post :-) One motivation for writing this post was that I was surprised to see how often the Facebook API will drop/omit data that exists and that you should be able to access. I specifically call out the Breakup Notifier app (which recently got a ton of buzz) because I don't see how apps like that can report accurate information when the underlying data is unreliable. Any thoughts or similar experiences with the Facebook API?
I'm the developer of Clarity (clarity-app.com), a Facebook Client for the Mac and I've had a similar experience. Here's another couple of things that are weird.<p>- you can't like pictures or even see likes for pictures<p>- you can't post on your wall if the attached image is located in your fcebook album: so if you want to post an image you have to upload it somewhere else.<p>- you can't rename friend lists<p>- lots of things are inaccessible if your friends have strict security settings (like their birthday, or their name)<p>- as outlined in the article: the notification data structure is a train wreck<p>- you can't approve friend requests<p>- some parts of the API are not documented at all, like the 'attachment' field on the posts table: it contains a dictionary, but in order to understand the keys and values you have to read the raw data from lots of posts, and even then you never know if one future entry breaks your app.<p>- and much more<p>One problem I had was that users expected much of this to work because it works on the Facebook iPhone app too. But that one is official and does not need to use the limited app API.
Great stuff, I'll keep this in mind as I build out the Appleseed Graph API. Especially good that you opened up with what you like about the Graph API, often-times articles like this skip right to the criticisms.
I recently spent some time integrating with the Facebook Credits API, and even though it's smaller, it's a similarly frustrating experience.<p>The documentation is sort of there, sometimes contradictory, and I <i>always</i> have to resort to reading their code examples in PHP to really figure out what data is expected, how to format it, and what I get back. None of their APIs are really well thought-out, they're all slapped together to sort of have all the relevant data. I understand that it's better to ship than not, but a little thought. Please?<p>The greatest irony though is that if you want to make a post asking for help in the official developer forum, you're met by this page:<p><a href="http://forum.developers.facebook.net/register.php?agree=Agree" rel="nofollow">http://forum.developers.facebook.net/register.php?agree=Agre...</a>
I won't go into the specifics of the article, because there are people far more qualified than I - I did enjoy it.<p>There's a lesson here in marketing: can you predict which name will get more buzz, 'Breakup Notifier' or 'Friend Mail'?<p>There's another lesson in marketing - you sell the sizzle, not the steak, but if the steak is awful you won't sell very many for very long regardless of how sizz-tastic your marketing is.<p>I can't compare both these products - and I hope they're both solid.
Good read. And a good reminder that you shouldn't (or can't) rely on documentation or a single request here and there when you decide to work with an API.<p>And that the amount of support and 'release cycles' (frequency of updates and fixes) is something that you should <i>always</i> consider when integrating another piece of software into your own system.
Anil, why didn't you just ignore fields and attributes that were missing? So if education:concentration returns "CompSci" on the first call, but then is missing on the second call, don't treat that as a change. Don't consider the attribute changed until the it is present <i>and</i> different.
I can understand all the complains about the facebook api, and they're all very valid, but my use of the facebook javascript API's have been relatively easy, to be honest. The documentation is far from ideal, and you have to figure stuff out by reading the actual response codes instead of trusting the documentation, but in general it all seems to work.<p>I am just wall posting and uploading photos though, and not doing any real data retrieval. Maybe facebook is more focussed on API's that put stuff in instead of taking things out? ;)
Having built a Facebook application that uses FB video I can understand where he's coming from. The Graph API is a great concept but like so many things Facebook, only halfway executed. It always amazed me that there are so many differences between a video in FQL and a video in the Graph API. In the end I figured out that "begin ... rescue ... end" was my friend when dealing with the Facebook apis. And about any call I make to the OpenGraph API is now wrapped in them.