Earlier this month, Facebook announced that it was giving up on the development of their official Java API client, a core component into building Facebook platform applications. It was apparently an effort that drained a lot of resources and was used by a decreasing number of people. We used the client extensively on one of our projects and in many ways found it to be deficient and sadly, weaker than the company’s official PHP client library. Several things appear to stand out here, in my quite humble opinion:

1. Major companies like official APIs

We worked with a major client on building a Facebook application and the notion of a supported client library was providing their IT staff many a warm fuzzy. Corporations love having a number to call to resolve issues, service level agreements (SLAs) and the such, and that is where the word ‘official’ holds sway. Corporations also love using Java, which is the de-facto co-favorite (with Microsoft’s technologies) on corporate servers. At the same time, Facebook never provided any SLAs or guaranteed any support duration for any version of the platform’s APIs. Furthermore, Facebook remains a fast-moving target in order to provide users with more features in a constantly evolving market. Time will tell if this has any effect on what was a corporate gold rush on Facebook.

2. Java is less important

It is clear that the vast majority of Facebook application developers use PHP as the application development language. Facebook itself uses PHP and writes many of the common applications using their own PHP library. It all appears to be working just fine, thank you. And while the back-end relies on everything from C/C++ to Java and even Erlang, providing Java developers with a client library seems less crucial to Facebook’s business goals. Java developers were quick to create their own libraries for Facebook’s APIs so the official library ended up facing competition from the start. What the official client had that open source clients did not and will not have is the ability to foresee and update immediately to API changes. So it is possible that the Facebook math is that few people actually use Java to write applications, those few people supposedly have funding (because Java is corporate) and therefore can pay or support client development themselves.

3. REST is difficult to write clients for

Facebook is using REST for its web service API. REST is good for small, nimble applications that need to work quickly with minimal processing overhead. REST’s weakness, in my opinion, comes from the fact that beyond documenting your custom protocol, you or the consumers or your web service need to maintain a codebase for a client. Google and Amazon buck the trend somewhat and still offer SOAP web services (alongside with REST). SOAP is the inverse of REST in many ways – heavyweight (lots of XML going in either direction), demands intense processing power and is difficult to be read by humans, as it is more geared towards machines. Yet generating SOAP clients after an API updates is trivial. You just tell your Java/.Net/Perl/Python/whatever SOAP client generator to look at the service specification (WSDL) and voila – you have a client. If you own the API, changing the SOAP service specification is almost as easy (one click does it quick in Visual Studio, for example). The Facebook platform is at the point where it is so expansive and capable that SOAP may be a better call.

4. Faint odor of Microsoft

I love Microsoft. I own Microsoft stock (about 3 or 4).

Let’s put the Microsoft conspiracy theory hat on: Microsoft owns a pretty chunk of Facebook and may be vying for more. In the place where the official Java client library used to appear, you now see a slew of exciting Microsoft technologies for your usage pleasure instead. Coincidence? maybe. Facebook has every right to do this and I am reading the tea leaves. At least Microsoft sees a return on its investment if only in a roundabout way.