In preparation for the Nordic APIs Seattle event, the speakers were asked a series of questions regarding the past, present, and future of API design. These aren't trivial questions; as developers and designers of complex systems it is important to revisit where we've been in order to steer where we're going. For posterity, I thought I'd share my responses.
How did you get interested in APIs?
One of my first API experiences, prior to the native-app fueled explosion, was to consume multiple partner APIs to create a new, unique experience (more here and here and here). Even in the "bad-ole SOAP days" it was obvious how powerful standardized patterns of reuse and interaction could extend "traditional" software development. It's not for everyone (or everything). But I've been accelerating data across increasingly frictionless pipes since.
What is/was the best API you ever used?
Everybody cites a handful of APIs worth emulating - Stripe, Twilio, SendGrid, etc. However, what I'm currently digging is a tool for creating APIs - Kimono Labs. Point it at any available website and it will take the structured HTML and turn it into retrievable API data. It is extremely powerful. Further, it underpins a point: if you don't have an API, somebody will create one for you. That probably sounds great to some businesses that have hesitated with their own API efforts. But why would you leave your brand, your data, and your potential customers in the hands of a 3rd party?
What is the most important thing to think about when a corporation creates their own API?
I believe the most important thing is the business model. The cost for taking on the entirety of an API's life cycle should be known before starting. While the "build-it-and-they-will-come" model is romantic, in reality, I've rarely seen it end well. ESPN, for example, appeared to create a public API that didn't have a clear vision for what developers were supposed to build with it or how customers would pay to help sustain it. That API is now, predictably, no longer public.
What is the future of APIs?
We are still in a period when people are wrestling with what constitutes a successful API. I'm sure plenty of folks also talked at great length about the benefits and correct implementation of the Interstate Highway system shortly after its inception, too. But that nuance is wasted on me - Interstates simply exist, are efficient, and I'm onto thinking about the destination at the other end. Mature infrastructure becomes invisible. We'll soon reach a similar point with APIs. We'll take for granted that there was a period when creating distributed software systems this way was a contested thing. In the future the only time we'll comment on an API is when it is missing (or in need of repair).
