Buzzing around the web APIary

There's a problem with single vendor events: it's easy for them to become echo chambers with their own reality distortion fields that quickly leave you feeling you're at a religious revival. Now that may be my innate British journalist cynicism showing, but I certainly found the Cloudstock pre-conference event at this year's Salesforce.com Dreamforce a refreshing change - an event that reminded me of O'Reilly conferences or Carsonified's "Future Of" events.

Cloudstock brought together a wide selection of different companies involved in the cloud space, from the obvious Amazon, Google and Yahoo!, to less well-known companies like Engine Yard and MongoDB. With informal presentations, and a developer audience, there was a lot to learn - as much from the Q&A as from the presentations themselves. Amazon detailed its web services infrastructure, while Adobe showed how to connect AIR and Flash applications to the cloud. Yahoo! Developer Network showed how to deal with latency issues for mobile sites using YQL to handle web service responses in the cloud, and Joyent's chief scientist discussed the economics of cloud services.

The topics might have seemed diverse, but there was a theme that brought them together, one that was neatly encapsulated in a presentation from John Musser of Programmable Web. There's one thing that makes for a successful cloud service: good, well-designed APIs. As Musser pointed out, they're important tools that make it easier to make money, to save money, to build brands, to handle moving applications and services from on-premises into the cloud, and to take advantage of mobile services and platforms.

There's been an explosion in the number of APIs. As Musser noted, it took 8 years to get a thousand APIs, and just 18 months to get the next thousand. That explosion hasn't stopped, either, with the number of new APIs released every month in 2010 twice that from 2009. There's a wide range of different APIs too, covering many many different market sectors and many different use cases. One thing Musser has noticed is that if there's a leader in one sector, then other sites and services quickly follow.

But not all web APIs are successful, and many fail to get significant adoption. There are a few things that go together to make a successful API. First and foremost there needs to be a developer need and an underlying service to support it. Secondly the provider needs a plan and a business model to support any APIs they launch. The APIs then need to be designed to be simple and open, facilitating easy adoption with minimal friction. Developers need choices around call types and data formats, as you're unlikely to know just what tools they'll be using to connect to your APIs, something that also means that there's a need for good developer support - including documentation, toolkits, and peer-to-peer support in the shape of moderated and managed forums.

There are many different data formats out there, from SOAP-XML, to Blaze DS, to XML-RPC, to JSON. It's JSON that seems to have captured developer imagination, and 45% of all new APIs are designed to deliver JSON formatted data. That's good for anyone using JavaScript, and it's starting to be supported by other languages - and if it's not supported, the format is well documented and easy to implement in your own code.

Musser thinks that we're still learning the best practices for web APIs, and the more mature APIs (especially those linked to popular services) are now adding versioning, keeping newer and older versions alongside each other and making it easier for developers to migrate over time, rather than having to cope with a sudden big bang change that may invalidate a key function. You can see this in action at Titter, which has changed its REST API URLs from twitter.com/ to api.twitter.com/1/.

APIs like this (especially the more mature type) are going to become increasingly important, especially as we move into a world where cloud services become important pieces of our infrastructure - something that's happening faster and faster with the rise of Platform-as-a-Service products like Microsoft Azure and Salesforce.com's Database.com. APIs are interfaces, and need to be treated like contracts between the provider and the user. It's something that SOAP tried to do, and as we take our service architectures out into the web, it's something we need to bring to simpler APIs - without removing their simplicity.

That's a challenge, but it's one that can be handled. If you're building web service APIs, take a page from Twitter's book, and make sure that you're using versioning - your developers will thank you for it.

Simon