Working creatively with APIs is one of the things that makes software development fun. APIs exist mainly to allow third parties to add functionality to software that the original authors don’t have the time, interest, or creativity to do on their own.
Most APIs are built to limit functionality, or more kindly, at least to encourage certain types of functionality over others. For about a year, I wrote software that worked with the iTunes API, which can be summarized as follows:
The iTunes API was clearly designed by committee. A bunch of people reserved a conference room with the noble goal of designing a way for other programs to interface with iTunes. They ended up talking about all the things that they had to prevent other applications from doing. Most likely, the concerns they enumerated included usability, security, piracy, loss of control, loss of revenue, and ongoing support.
As a result, most applications that use the iTunes API are glorified remote controls. The deeper integration that you see in products like our SpotDJ Classic and iLike are, put simply, total hacks. We used the APIs in ways that it was neither designed or intended for. As a result, we spent a lot of time futzing with undocumented hacks and less time building great new features.
When I start looking at a new API, I generally begin with two things. First, what do the sample apps do? Second, what are the API calls? Most of the time, this gives me a pretty good sense of what the designer intended. When the Facebook platform was released, it only resulted in more questions. The reference app for developers was called “Footprints.” It was an app so simple and uninteresting that I don’t even remember what it did. It largely served to educate developers about Facebook’s novel approach to developing add-ons for a web site — specifically, a REST-based API to obtain information from the service with a custom query language and a homegrown markup language to leverage the existing user interface and functionality of the site. The documentation was sparse, and completely unwritten in some points. It failed to answer basic questions like “What is a ‘wall’? How do people invite other people to use my app? What’s the best way to do X? Is it okay to do Y?”
Whether by design, through evolution, or just happy coincidence, the Facebook API inspires rather than limits. Instead of sitting down and making a list of use cases that they wanted to prohibit, the Facebook developers most likely listed the different parts of their system and brainstormed how to expose them to developers. I’m sure that examples of possible applications were discussed, but the smartest move was recognizing that the truly valuable applications were the ones that Facebook itself hadn’t yet thought of.
When we work with clients on Facebook applications, one of the approaches we use, either internally or with the client, is to focus on a particular part of the API and brainstorm ways that it could be used for their application. Note that this wouldn’t work so well for an API like iTunes (“Let’s do something really unique with pause();!”) but it works quite well with the Facebook API (“What do feed items mean for a game?” “How can we use a profile action to encourage replay?” “How will users want to stay connected via the mobile API?”)
As the API has grown and thousands of apps have been released, best practices have emerged along with novel implementations that stretch the boundaries of the API and inspire developers to further explore what’s possible. At the same time, a developer community has built out documentation, frameworks, and guidelines that Facebook itself supports and encourages. As other networks release their own APIs or implementations of OpenSocial, it will be interesting to see which ones limit their developers and which ones take the less prescriptive approach and really foster creativity.