Back in the early days of Web 2.0 exuberance, all the hot new online services (Flickr, Delicious, and even Twitter) built largely open APIs and encouraged developers and customers to build mashups: fun but fleeting ways to juxtapose data from multiple sources on a single webpage. These companies seemed to believe that enabling people to create new and unexplored tools on top of their data would produce magical, unexpected innovation that would make the entire platform richer and ultimately accrue benefits to them. For a time, nearly every consumer startup seemed to launch with an API ready to go, even if their company didn't yet have enough usage to make developing on that API worth people's while.
Unfortunately, as the early mashup excitement waned, these companies figured out they had to earn money and exert more control over their platform. Watching Twitter stumble drunkenly through that process has been particularly entertaining, but the gradual falling into disrepair of many other companies' APIs may ultimately be worse for the web community as apps break and the features of the product diverge from the features of the API.
In recent years, though, a different approach to APIs has emerged. Companies like Twilio and Stripe are rehabilitating the idea of an API from the legacy of failed late-2000s startups and going "all in": the APIs these companies provide are not just important, but the core product that each of them sells.
These companies have figured out two fundamental things about APIs:
- The best APIs aren't for your product but for a problem.
- You must put as much effort into the user experience of developers who want to use your API as you do in all the other elements of your product.