[FuzzyDunlop]

I might be a bit naïve thinking this, and I only ask out of curiosity, but, OAuth non-browser implementation issues aside, what drove the decision to support four individual SDKs to access the Graph API as opposed to building the Graph API up into a resource that, like a well implemented REST API, could be used easily by anything that can make an HTTP request?

From that position, the open source community, or any enterprising developer for that matter, has a single, standard, and well supported API they can then write a language specific library for and maintain.

Like I say, I'm not privy to all the details behind this, and I'm being wilfully ignorant, but it intrigues me that the developer of an API feels that it needs to then support its own abstraction of it for a limited number of platforms/languages.

[synotic]

I don't know the details, but to your and latchkey's point, I think the reason they support these SDKs (in addition to their generic Graph API) is that they're consumers of those SDKs. They have an iPhone app, an Android app, use JavaScript and probably the PHP SDK for internal stuff. So they're just making these public since they're good enough for internal use.

They could probably easily hire a Python coder to maintain a Python API (and Ruby, or whatever language), but it would be unrelated to the main work they're doing and probably lag behind since those languages are either little used or not used at all in house.

[scarlson]

FriendFeed, acquired by Facebook in 2009, was a Python shop. These guys now maintain their Tornado platform as Facebook (https://github.com/facebook/tornado). Facebook's CTO, Bret Taylor, is a Python guy (https://github.com/finiteloop).

Python is used in house. They have the resources to support Python. They've just made the business decision not to.