APIs as an indicator of platform health

I've been doing some active investigation of the APIs available on some of the new breed of web platforms. It's perhaps not immediately obvious to the casual user how important these APIs have become, but they are central and critical parts of how we all experience the social web today.

Many of the social sites we all use have published and open APIs that anyone can code to and integrate with their own websites or mobile apps. These include Foursquare, Facebook, Twitter, TripIt, Yelp, Qype, LinkedIn and others. The availability of an API is a good indication that a web site is aiming to be a business platform rather than just a simple web site on its own. A platform implies it attempts to increase its value by joining forces with partners who can increase that sites value by complementing it.

Just a few examples to highlight where APIs are being used:

• Instagram publishes your photos to your connected Foursquare or Facebook accounts through the Foursquare and Facebook APIs. Without those APIs Instagram would probably never have become the hit it was and not been bought for $1bn.
• Spotify connects to your Facebook account, again through the Facebook API, allowing it to publish to your Timeline details of the songs you listen to.
• Those mobile apps you use to look at your twitter stream & tweet all connect via Twitter's API.

Can you notice one common theme? All of these complementors that use the platform APIs tend not to just get data from the platform, but also write data back to the platform - in effect, providing value back to the platform - a true win/win for both parties. E.g. Spotify gains because their service is more attractive due to its integration with Facebook, but Facebook also gains because the additional data that Spotify writes to users timelines increases the value of the social network itself.

Underlying all of these APIs are two enabling technologies. All of my examples use both of these - they are now pretty ubiquitous:

• OAuth, which provides a security mechanism that allows users to grant the authority for their accounts to be accessed by an external website or mobile app. Despite the tortuous nature of OAuth as a programming model and the frankly embarrassing way that the spec can, and is, interpreted differently by many implementors, it has provided a very successful enabler. OAuth has a fairly involved process that eventually results in an authentication token being passed to the app that has been granted authority to access a users data. Once you have the token you can access API data, but the user can revoke the token at any point through the platform's service, so remains in control.
• JSON as a way of structuring data in a very simple manner that streamlines the code you write to access an API. In particular, many popular languages make reading JSON outrageously easy. In Objective C, for example, 1 line of code turns any JSON string into a native object that can be very easily manipulated. In comparison, the previous 'standard' of XML had its own tortuous programming model to learn. JSON has done away with this and the programmable web is all the better for it. There are too many things to learn and a programming model for manipulating data is not one you need, trust me!

With these two basic technologies this interconnection of the web and mobile apps has been enabled. It's how websites integrate and share data and it's how nearly all mobile apps interconnect with the web to provide that unique app interface onto existing services. Facebook's audatious attempt to map everything and everyone through Open Graph depends on OAuth and JSON. They are the Infrastructure of the programmable web.

It's also interesting to look at the maturity of the different provider's API implementations. I suggest the following measures of maturity:

1. Quality of documentation. Some sites have documentation, but it leaves you guessing on major points.
   
2. Active community of users with forums to share and resolve problems. Most, maybe all, sites have web forums but the level of participation and help varies widely.
3. Formal test tools that allow an API user to test parameters and validate their usage of the API independent from their code, thus isolating API usage issues from programming issues. Testing of some APIs appears only possible by writing code, which leaves you wondering if a problem is because you're passing the wrong data, or if your code is just dumb. Other sites provide a very neat web test tool to try out API queries and test different ways of exercising that API.
4. Availability of example code to exercise the API in popular programming languages and environments, most typically JavaScript, Objective C and Java. Some sites tell you how to do it, but without sufficient example code you're again left to work out the specifics of your environment for yourself.

In my experience of testing some of these APIs, not all sites meet all four of my maturity tests. Facebook is the only API I've found that meets all, and in a quality way. The Facebook "Open Graph" API is impressive for not just it's quality (meeting all tests) but also because of the ambition of its purpose and potential - to more or less map and interconnect everything and everyone. With the thought that's gone into the implementation, Facebook maximises the number of people using it - in my experience it was the easiest to get working. (Once I'd convinced Facebook i was a real person - they were the only site to suspend my account because I hadn't provided enough context for them to be convinced I was real! Facebook don't like anonymity.) The difference in effort for getting something working between the best and worst can be significant. In one case I abandoned my efforts in frustration, the site losing a potentially valuable integration (imagine if I was Instagram).

Some sites eschew such integration and open APIs. TripAdvisor, for example, strictly limits access. It seems pretty successful on its own, so I guess they take the view that sharing their data is more of a threat than an opportunity. Will this limit their growth longer term? It might. I see more review comments going in Foursquare, Yelp, Qype and Facebook, so this might threaten TripAdvisor if they don't open up. Interestingly they are also partnering with Facebook, so that will be interesting to watch.

One other point of interest is the increasing use of OAuth to obviate the need for new web or mobile services to create their own user authentication system. More and more I see the option to 'login using Facebook' on new websites or apps, so I don't need to create another Id/password. Will Facebook become the user authentication system for the web? Maybe. That sounds a bit scary to me, but it's possible. Certainly technically possible. Given their understanding of people and relationships they're in a pretty strong position to do this. A couple of years ago we were speculating that banks could do this, now its Facebook - its interesting how things change. For some users, Facebook probably knows more about them than their bank - imagine what they could do with that insight (pretty useful stuff for credit scoring, for example).

What about banks - should they provide public APIs? I think they should - it's up to customers how they allow their data to be used, but opening it up could present all sorts of opportunities we can't imagine today. Radicall stuff!

I hope you've found this quick canter through the world of web APIs, their maturity and implications interesting. Just one more thing.....what about corporate IT? Why don't they open access to systems using OAuth and JSON internally, create support forums, example code and test tools for internal use? It strikes me there is a huge opportunity for big organisations to maximise their agility potential by learning from the Facebook's of this world. Instead of the rigid and secretive approach that typifies corporate culture (try finding API documentation in most large corporates), why not open up and use social business tools to create an active community of API users and developers? Blogs, wikis, web forums are the life-blood of support structures for many web APIs - its time the same tools were applied in the corporate world. And the corporate standard of WebSphere has included JSON and OAuth support for some years since the availability of the web 2 feature pack in 2008. Something to think about...