Showing posts with label Facebook. Show all posts
Showing posts with label Facebook. Show all posts

Tuesday, December 4, 2007

What's wrong with the Facebook API

I've been working with the Facebook developer platform for a few weeks now and have decided to vent some of my opinions about it. I've been heavily interested in Web Services, particularly RESTful ones, lately and have noticed some things about Facebooks "REST" API.
  1. Verbs are important!: For the Facebook API, verbs appear to have no real meaning. A POST can be used inplace of a GET or vice-versa. And PUT and DELETE aren't discussed at all.
  2. Separate Resources are good!: This one makes me real mad...let's say I perform a GET on this URL: http://myserver/user/1821389/friends . What do you think this will do? In my very limited REST knowledge (and a bit of common sense) I would say this will give me all of the friends for user 1821389. Or perhaps I perform a POST on the URL: http://myserver.com/albums with a body containing some sort of "albumTitle"? In either case, it seems obvious what the action will do. Lets take the Facebook "approach" now: POST on http://facebook.com/restserver.php?method=friends.get . What do you think this will do? I did a POST on a generic Resource (restserver.php) and invoked some query for "friends.get". Looking at this without knowing the actual truth, I might think I am adding a new friend to a list of friends for someone (not sure who though). In fact, I'm getting a list of friends for a user.
  3. Inconsistent return formats are bad!: One thing that Facebook does which I think is a good idea is they offer 2 return formats for requests: XML and JSON. Here's a little taste of the same response in different formats:

<friends_get_response xmlns="http://api.facebook.com/1.0/" xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://api.facebook.com/1.0/ http://api.facebook.com/1.0/facebook.xsd" list="true">
<uid>51824</uid>
<uid>8361861</uid>
...
</friends_get_response>


and

[51824,8361861,...]


I won't go into major details here, but my major issue is with the lack of "tags" or identifiers in the JSON response. I know that JSON is supposed to not be as heavy as XML, but something similar to:

{ friends : [51824,8361861,...] }

Would be a little nicer to work with.

Ah well...I guess you can't have everything in this world.

Thursday, November 29, 2007

Facebook Spaminess

There's an interesting little debate going on in the Facebook Developer community regarding "spaminess". Spaminess is a term used to describe how spammy a Facebook application is to non-users.

A little background:

All applications have the ability to hook into the Facebook platform to do many tasks including getting information and posting information about a user (all using a REST interface, that in my opinion is not RESTful). Getting is pretty obvious: give me all the friends of a user, etc. Posting is a little different. You can post news stories, photos, notifications and invitations. The latter 2 are the points of interest.

A notification is a message usually saying something along the lines of "person x did thing y to you". It is almost always a personal message directed at the recipient. It can be sent to both users and non-users of an application.

An invitation is as it sounds...an invite to a non-user to add your application.

So where does spaminess fit in?

Here's the UI from the invite page:


Here's the UI from the notification page (with the little X pressed)


Notice any differences? I sure do, but Facebook doesn't seem to. So spaminess...as you can guess, if a non-app-user hits the little X button on the Notification page for your app, you get a spam marking for your app. If that happens enough your spaminess level rises, and you reach the Blocked status: no notifications will be sent to non-app-users... a.k.a. your app is ruined.

Why not just always send invites to non-users instead of notifications? The short and fun answer is that Facebook recently removed the ability to RESTfully post multiple invitations to users (like you can post multiple notifications to users). Instead, you can provide a button in a form that users can click to send an invitation to a single user.

According to this bug in the Facebook Developer area, Facebook is looking into the problem and will try to fix it. But for many developers, its a little too late. Our Christmas Fun! application has taken a huge hit in growth since this problem started to show up.

Sunday, November 18, 2007

Facebook Application Reference

For the last few weeks I (along with some friends) have been developing some Facebook applications. Our first release: Christmas Fun! has been fantastic, growing incredibly fast in just the first week and a half. We are working on getting our second app done and are hoping to push it out by the end of the week.

During all this time, we came across a few things that we hope might help other developers:
  • Store Facebook UIDs if you want to do profile updates - there doesn't appear to be a simple way of getting all of the users of your app, so storing them is the easiest way we could find to do mass updates
  • Notifications.send & feed.publishTemplatizedAction - Here's what we found: notifications.send() is basically telling user A that user B did something to them. It also sends an email if configured (an extra parameter). feed.publishTemplatizedAction() is a way of telling all of user A's friends that user A did such-and-such. It also appears to be able to do aggregation of news stories, but we aren't 100% sure. As well, make sure to read the docs on the usage of the tag in the notifications (ie: if you don't place one at the start of your notification, one will be prepended)
  • Images need absolute URLs - or Facebook will yell at you. And make sure the URLs are back to your host and not through Facebook. We recommend having a variable that stores your host in case you ever need to move hosts.
  • Javascript - This is a big one...there's a few things to note here: 1) Facebook proxies your Javascript, so if you get errors using Firebug (or another tool) don't get freaked out if you see "app7291713u1241204901231_foo()" as a function. 2) If your code doesn't work as you thought, double check the FBJS DOM - Facebook likes to give a few different Javascript functions for handling properties.
We'll be sure to add in some more findings as we come across them.

Wednesday, November 14, 2007

Christmas Fun! is Live

After a few weeks of exploration, discovery and heart-ache, we have finally released our first Facebook application: Christmas Fun! This app does 2 main things:
  1. Provides a countdown (to the second) of the time until Christmas
  2. Allows users to send/receive gifts
The whole experience has been educational. We learned about how notifications work (news feeds, profile updates, emails), how FBJS works with code and a few other things.

Within less than a week we had jumped to over 1000 users with over 3000 gifts sent! We are still working away to improve the UI and are coming close to releasing our second Facebook application!

This has also been quite different since we built the entire app in PHP which I have barely used, but have come to appreciate its scripting capabilities.

Saturday, October 20, 2007

fb_sig parameters

I've been working away at building my own java library for Facebook applications (Java-Spring-Book) and came across something today that was a little different.

For Facebook API calls, you need to have a session_key as one of your parameters. You get this key by asking for it with authToken. Nothing special here. So, my original plan was to store this session_key so that I didn't have to keep requesting one (and I'm sure many other people would do the same). For simplicity, I decided to store the key in the user's session.

As I started working away, I noticed that I wasn't able to store the key in the session (it was always blank on subsequent calls). Without going into the session more, I decided to try simple http cookies. They may not be the greatest, but they should do the job. Again, they weren't working. Cookies didn't seem to persist across subsequent calls. Strange, no?

From the looks of it, my code was working totally fine. There really wasn't any information in subsequent sessions or cookies. And from what I can tell, that's all by design. Here's my theory as to why:
  • In your application setup, you can tell Facebook whether you want to use FBML or an iFrame to display your content (FBML is a bunch of custom tags that make building apps easier)
  • In order to properly render your page inside of Facebook, a request from the user goes to Facebook to show an app. Facebook then sends a seperate, distinct request to my server to get my content. However, this request is different then the user's request, and appears to be blank each time (no persisted info). The result? No cookies for you!
So how can I go about "storing" a session_key? I don't think I have to. From the looks of it, when Facebook makes a request for my page it appends a bunch of "fb_sig_" parameters (including one for session_key). It looks like I can use these parameters in my calls.

I took a quick look through the Facebook docs and couldn't find anything. Anybody know where this might be at?

Building Custom Facebook Apps

Facebook...what a great thing. Taking a simple idea of friends, Mark has been able to create a company that is probably worth something in the billions. Not bad for someone whose my age. So now that I am in fourth year at UW for Systems Design, my friends and I decided that a design project around Facebook might become profitable (not to mention fun).

Now that Facebook has opened its developer platform up, anyone can make their own applications that users can add to their profile, and for the lucky ones, make a little money. There's even companies (such as Slide) that are based specifically around building custom apps.

Our goal? Well...something that makes something about building apps a little easier. And quite obviously, we have no idea what that something is.

So, now 2 months later, we are well on our way. The 2 other group members are looking at a fairly well-developed PHP library that Facebook provides. They seem to be having a lot of fun and finding it rather simple. And me? Not as much fun. I decided to take the Java approach. And let's just say it hasn't been the most enjoyable or easy experience of my life. But I am learning a lot.

Why isn't it so fun? Well, the Java library Facebook provides is for desktop applications, not web based apps...so some subtlety's cause some problems. But, me, being the try-hard that I am (ha!) has decided to build my own Java library...no small feat mind you.

But I did try something I've never done before (and have been silently inspired by my boss): I've started an open source project around it: Java Spring Book. Right now, it's in a very early stage...I'm still trying to figure out the details. Hopefully, someday it will be in a position to offer some help to new developers (who are like I was when I started).