What is an API?
Over the last year, I’ve participated in lots of conversations across domains — in media, and particularly in ed-tech — about APIs and how they affect the way we use the internet. Particularly in education and in open source circles, there’s also been a lot of talk about personal APIs, or the personal cloud.
I want to talk through what an API actually is (and what it isn’t), and then discuss some of these open source ideas.
API: Application Programming Interface
When you interact with software, you use a human interface. The browser or app you’re reading this with right now has a set of icons, menus and visual elements that allowed you to get here. It’s designed for people, and some of the best apps spend millions of dollars getting that interface just right, so that you can perform tasks easily, and the companies behind them achieve their goals.
Sometimes, online services and other software make some of their functionality available for other software to use. For example, you might incorporate a stream of tweets from Twitter into a topical website. Or you might use Google’s mapping functions to make a new kind of fitness app.
They don’t do this for love. For example, Google knows that if more people depend on its functionality for mapping, it has business leverage that it can use to make a profit. Allowing these integrations is always a strategic business decision.
To allow these integrations to happen, platforms create Application Programming Interfaces (APIs). While human interfaces are designed for people to directly use, APIs are designed for software developers to access with software code. Usually it’s a bit like having an invisible web browser inside the app, which accesses special pages that return data instead of human-readable text. That data can then be used in the app. For example, you might give an API endpoint a latitude and longitude, and it might return the name of the nearest city.
The easier it is for a software developer to build software that uses an API, the more of them are likely to do it. Twilio, which provides integrations with traditional phone networks, and Stripe, which is a credit card payment processor, both became big, influential companies by having well-designed, easy-to-integrate APIs.
Because of this strategic importance, every company’s API is different. No major software provider shares an API with another. If you integrate with Google Maps, for example, you then have to write a completely new integration if you want to integrate Bing Maps, or OpenStreetMap.
Another example is Slack, which is currently building an ecosystem around its product by creating easy-to-integrate APIs for bots and other software. Every company who builds or uses one of these bots is now dependent on Slack. Its API allows you to leverage its platform, but in return you’re locked in.
APIs are incredibly useful, but they’re not magically adaptable ways to hook software together. I’ve heard this fallacy a lot, and it simply isn’t true. One API: one integration. Two APIs: two integrations.
Building houses on sand
Imagine you’ve built a business using another company’s API — and then, suddenly, they decide to change it. Perhaps they’ve chosen to rate limit it (so you can only use it below a certain threshold on any given day), or they’ve decided it’s no longer in line with their business strategy and removed it entirely.
This has happened many times, and many companies have gone bust as a result.
One commonly-repeated warning story involves Twitter. Once upon a time, over 80% of Twitter’s traffic came from third-party software using its API. There was a thriving ecosystem of developers and companies that helped Twitter become popular.
And then, one day, they decided to impose strict rate limits and other terms that effectively made those companies untenable. This was their right — and they arguably needed to do it for the viability of their commercial platform. However, the change was heinous enough that Jack Dorsey has since apologized.
Facebook saw this as a way to take strategic advantage, and began to offer a 2 year stability guarantee for its API. Still, after two years, all bets are off.
One note: the Google v Oracle trial result earlier this year found that cloning APIs is fair use. This means that a company could theoretically take advantage of this kind of situation — or just create competition in the market — by offering a like-for-like API, and encouraging disenfranchised developers to switch vendors. This strategy has never been tested between two commercial web services, however.
Open APIs
One way to overcome this kind of vulnerability is to create a community-designed “open API”. Here, multiple software vendors agree to allow developers to use the same API calls, so a developer can change from one API provider to another without rewriting their code.
Unsurprisingly, this has not been a successful endeavor outside of open source platforms. Why would a company relinquish such a strong strategic advantage?
Even in the open source realm, APIs are becoming more proprietary. WordPress and other blogging platforms used to use something called the MetaWeblog API. This meant that any developer could write a blogging client that would be compatible with WordPress, MovableType, and a host of other platforms. However, WordPress long became the open source publishing victor, and it’s been moving towards a platform-specific API. The new API is undeniably more powerful, but it loses its predecessor’s openness and platform agnosticism. Applications that use this new API are locked into WordPress.
Towards personal APIs
The vision of a personal API is one where the user is at the center of their applications and data. Here, the user dictates the terms of use, rather than the application vendors — and services become locked into their users, rather than the other way around.
In many ways, the idea is similar to the Vendor Relationship Management idea promoted by Doc Searls and others, where customers manage their vendors much like a corporation might manage its suppliers. The IT security analysis firm KuppingerCole described these models as follows:
[They] will change the way individuals deal with sensitive information like their health data, insurance data, and many other types of information — information that today frequently is paper-based or, when it comes to personal opinions, only in the mind of the individuals. They will enable new approaches for privacy- and security-aware sharing of that information, without the risk of losing control of that information. A key concept is “informed pull” which allows consuming information from other parties, neither violating the interest of the individual for protecting his information nor the interest of the related party/parties.
Earlier this year, the API evangelist Kin Lane said personal APIs are inevitable:
First, I’ll set the stage with what is a common reaction, when I mention the term “personal API” to other API folk in the space: “Its a nice idea, but it just isn’t something the average person will ever need, let alone care about what an API is — it is a non problem.” To me, that response sounds just like what you’d hear in early 2000’s when asked if any single individual would ever need a web presence — something that blogging and the social media star has continued to evolve, while also proving the naysayers wrong.
In order to commoditize API relationships, these models arguably depend on open APIs: you need to be able to switch vendors simply.
For the strategic reasons I’ve discussed, this isn’t something most businesses will jump into with open arms. However, there are controlled environments where it may work — like, for example, universities.
Phil Windley is working on a personal API at Brigham Young University:
Unlike others who attempted personal APIs, we’re lucky in that we control both sides of the transaction. That is, we have control of the university systems and we have students who will generally use the tools we build for them. So rather than build a conventional tool to, say, create a directory, we can build one that uses the student’s personal API. The university systems still work and students get a new tool that they learn to use. This is meaningful because students have a significant number and variety of interactions with the university, making it a great place to explore how architectures based on personal APIs can be designed and used.
A lot is involved. BYU has the concept of a university API — in fact, 261 of them — which provides a common interface to campus functions. They are able to dictate how these are integrated in the scope of campus software, and, as a large university with buying power, potentially have some influence with their vendors.
Silicon Valley is firmly set in the APIs-as-lock-in model, for a host of reasons. It’s perfectly reasonable to assume that another model may emerge, but just as the web came from academic research, it’s possible that academia will be at the forefront here. Make no mistake, there's serious commercial potential here — think personal bots — but there will be a long road ahead.
So why use APIs today?
The biggest reason to use APIs is to avoid re-inventing the wheel as a software developer. You’re probably not going to build your own fully-featured mapping application, so if you need a map in your software, it makes sense to integrate Google Maps or OpenStreetMap. You don’t want to build your own credit card processor (trust me), so it makes sense to use Stripe. You’re going to have a hard time building a market of millions of enterprise software users, so you’re going to piggyback on Slack. And so on.
APIs present a pragmatic solution that allows us to build on other software while saving on short-term costs. They’re not a magic wand, but used wisely, they allow us to build entirely new products and services. And maybe — just maybe — they will allow us to take control of our digital lives and build a new kind of internet.
