From Facebook Developer Wiki

How do apps add tabs to profiles? Is this working now in the sandbox?

Sigh...always changing things. If you're going to redefine what is essentially a public API, then why not do it in a way that will not break things for users? As in, instead of changing some methods to no longer require a session key, and then have them raise an exception if a session key is passed, just have them ignore the session key if they don't require it. And as in, instead of removing deprecated API calls, refactor the server-side logic for the old API calls so that they just internally invoke the new API calls. Mark them as deprecated in the documentation, but don't raise an exception if people call them. There's no reason for changes made to a public API to be made in a way that causes breakages. Or to put it another way, when changing a public API, every effort *must* be made to preserve backwards compatibility. If you don't do that, then you are a poor custodian of the API, and some other entity should be chosen to maintain it.

[edit] comments on session keys

comments were removed from the main page. they are re-inserted, here.

The session key you'll get will last one hour, so, for example, you won't be able to post News Feed stories for a user after the user's session expires. However, when the user approves your application's Terms of Service, you can offer the user the option to grant an infinite session (provided the user agrees to be kept logged into your application). And you can store a session key each time a user interacts with your application. The session key you'll get will last one hour, so, for example, you won't be able to post News Feed stories for a user after the user's session expires. However, when the user approves your application's Terms of Service, you can offer the user the option to grant an infinite session (provided the user agrees to be kept logged into your application). And you can store a session key each time a user interacts with your application.

lkcl2008jul25: DON'T DO THIS! LEAVE THE SESSIONS AS INFINITE. i have an AJAX+JSON web application, not a dumb "php pages" application! the JSON responses coming back from the server would require an absolutely AWFUL arrangement. a response would need to go back, from the JSON code, "the session has expired!". in the AJAX application, every single JSON response would be required to look out for this message, and - this is the awful bit - redirect the user to a login page. in an ordinary web application. that would be absolutely fine... but in an AJAX application, it's not in the slightest bit fine, because the user continuity off the page is entirely lost, and made horrendously complex to restore, to come back from the facebook "login" page.

[in an earlier login incantation attempt] to get round this, i tried embedding the facebook "login" into an iframe: facebook has code that jumps the web page OUT of the iframe and takes over the entire page, destroying the AJAX application.

if i'm misunderstanding you, here, i apologise for grabbing your attention in bold :)

(643742326 08:13, 7 August 2008 (PDT) - pete, i moved reverted and really quite important comments on this session key change into the "discussion", so that the comments are not destroyed and lost. facebook REALLY needs to look very very carefully at how AJAX-based web sites will interact with the facebook API: it's not straightforward).