Social Media API Gotchas
I’ve been heads-down for the last few weeks developing the web site for the new PUMA Social campaign. A major part of this site is a web-based game that rewards users for performing activities on various sites across the internet, and as such, I’ve become intimately familiar with the APIs of several popular web sites and their various — shall we say — quirks. I’ve collected the most egregious here with the hope that I can save the next developer a bit of anguish.
Facebook Graph API for “Likes” is busted
Facebook’s Graph API is awesome. It’s fantastic to see them embracing REST and the open web. That said, the documentation doesn’t paint an accurate picture of the Graph API’s progress, and there are aspects that aren’t ready for prime time. Specifically, the “Like” functionalty:
-
For a page (like http://www.facebook.com/puma), you can retrieve a maximum of 500 fans, selected at random. For a page with more than 2.2 million fans, this is of … limited use.
-
For an individual item like a status update or photo, you can retrieve a list of the people who’ve “liked” it, but it’s a small subset of the people you can view on the site itself. You might think this is a question of privacy, but I found that some users who are returned without providing authentication information are omitted when authenticated.
-
For individual users, accessing the things they’ve “liked” only includes pages, not normal wall activity or pages elsewhere on the web.
Facebook Tabs retrieve content with POST
Facebook lets you put tabs on your page with content served from third-party websites. They’re understandably strict about what tags you’re allowed to use — no <script> or <body> tags, for example — and they typically do a good job explaining what rules are being violated.
On the other hand, I configured a Facebook app to pull in tab content from our Ruby on Rails application and was greeted with the unhelpful “We’ve encountered an error with the page you requested.” It took a lot of digging, but I discovered that Facebook retrieves tab content with POST (rather than GET) requests, and what’s more, it submits them with a Content-Type header of “application/x-www-form-urlencoded,” which triggers an InvalidAuthenticityToken exception if you save anything to the database during the request/response cycle.
Twitter Search API from_user_id is utter crap
Twitter has a fantastic API, with one glaring exception. Results from the search API contain fields named from_user and from_user_id; from_user is the user’s Twitter handle and from_user_id is a made-up number that has nothing to do with the user’s actual user ID. This is apparently a known issue that is too complicated to fix. Do yourself a favor and match by screen name rather than unique ID.
