(Reprinted from my blog post here, because I thought use.perl might be interested)
This post is a record of a day or so's experimentation building a Facebook application in Perl. It's probably applicable to writing applications in Ruby or Python, since it contains pretty much nothing that's Perl-specific. I thought it would be particularly useful to write it up because Facebook only officially supports Java and PHP, so almost all existing instructions are in those languages. I may continue hacking around with building this application in future, and if I do I may make this post the first of a series.
Firstly, a confusing piece of nomenclature. There is a Facebook API, and there is even a Perl implementation of it called WWW::Facebook::API, but this is not (necessarily) what you're looking for: this is for building applications that use Facebook (say, for when you want to build a Perl script that can list all your Facebook friends), not for building Facebook applications. It's like the "well, he's a friend who's a boy, but he's not my boyfriend" thing.
Facebook applications are programs that integrate seamlessly with Facebook. You can find a ton of them advertised publicly on Facebook, and there are many more which aren't part of the public directory. Anything listed in that bar on the left-hand side of your page is a Facebook application (but applications don't need to be listed there).
So, what do you need to make a Facebook application? You just need to be able to write a CGI script (or mod_perl or whatever). If it needs to integrate with the other parts of Facebook, then it can use the Facebook API. Otherwise, there's no need.
In order to make your application, you need to add the "Developer" application, which is an application for making applications (yeah, it's a bit meta). After that, you can click "Set Up New Application" and add your new application. There's some terms of service stuff to agree to and so on. You get to choose between "website" and "desktop" application types; I've only experimented with "website". You don't have to fill in "TOS URL" at all.
Most of the other fields you're asked to fill in are self-explanatory, but there are two which puzzled me a lot, and I had to spend some time playing around to find out what they do. The fields are Callback Url and Canvas Page URL (no idea why the capitalisation is different). I'll explain what they do in case it saves people some time.
Canvas Page URL is easier to explain. It's of the form http://apps.facebook.com/your-application-name/. This is the URL at which your application will be visible within Facebook. If you decide to put an entry in a user's list of applications at the left of the screen, the link for your application will go to this URL. If you're wondering where Facebook gets the content for this page, we have to go on to talk about Callback Url.
Callback Url is the address of your CGI script (or whatever) on your own server. Whenever anyone goes to the URL you set up in Canvas Page URL, Facebook's server will make a POST request to this URL, with certain parameters to tell you which Facebook user made the request and so on. Your script serves the content in a special markup language called FBML, and Facebook then serves it to the user within their ordinary page so that it looks just like part of their site. (Usefully, if they go to http://apps.facebooks.com/your-application-name/anything-else, Facebook will add /anything-else to the URL of the Callback Url it calls: you can test for it using path_info() in CGI.pm, or with $ENV{PATH_INFO}.)
Alternatively, you can elect to use an iframe, in which case a largish iframe will be generated, and pointed at your Callback Url with the relevant values passed as a GET (obviously, since you can't do POST through an iframe). Then you serve the content in HTML (or anything else the user's browser can handle) and the user sees it as usual. I'm a bit puzzled as to why anyone would want this, since a) you don't get to do fun stuff with FBML (though maybe there are things FBML doesn't do that you'd want to), b) you have an iframe on the page, and iframes are generally ugly, and c) the user can find out where your server is and what your script is called.
There's another thing that Callback Url does. Suppose you have a website called i-like-cabbage.com, and you want a way of putting a link on that website which adds the i-like-cabbage Facebook application, and then sends the user home to i-like-cabbage.com so they can carry on as before. There is a way to do this, but it's outside the scope of this post. If you do this, though, Callback Url is where you get sent when you're done adding the Facebook application; you can tell the difference between this and the Canvas Page URL request because it will be a GET rather than a POST (unless you've decided to use an iframe). If you don't get users to connect in from an external website to add the application, you don't need to bother about this. So why am I telling you? In previous versions of the Facebook applications spec, this was all that Callback Url did, and I'm telling you this particularly because a lot of the documentation will tell you that that's all it still does. (For example, the strapline explaining Callback Url on the "edit application" page says: After logging into Facebook, users are redirected to the callback URL.)
So, there are the basics. Facebook has a developers' site with documentation, and there's a developers' group where you can ask questions. There's still a bunch of stuff I don't understand, but I'll come back and write it up as I find out.
>>> Later: what I found out.
Re:working?
marnanel on 2007-05-29T03:50:59
I've only experimented with web applications so far. Do you have anything that does work that you can pare down to see where the problem is? Did the people on the developers group offer any useful suggestions?
(Goodness, this entry is now the seventh hit for "facebook application" on Google, two days after I posted it.)Re:working?
educated_foo on 2007-05-29T12:35:59
PEBKAC, humiliatingly enough -- I was misunderstanding what they were trying to do with their authentication. But as far as I could tell from the #facebook IRC channel, I'm one of very few people trying to create "desktop" (i.e. command-line) plugins.Re:working?
marnanel on 2007-05-29T12:54:53
PEBKAC, humiliatingly enough
No worries: happens to us all.
I'm one of very few people trying to create "desktop" (i.e. command-line) plugins.
*nods* I was sort of getting the impression it's much less common, too. Well, if you get something working and you post it as an example for how to do desktop FB apps, I'll link to it from this post so people can build on it. Otherwise, I'll try to put something together myself in a few days and upload that.Re:working?
educated_foo on 2007-05-29T17:00:49
Well, the beginnings are at WWW::Facebook::FQL on CPAN. You have to sign up for your own developer key before doing anything useful. I find the SQL-alike interface much less painful than the object-oriented PHP, and I just wanted the simplest possible thing that would let me play with the data.
