Is this the end of the API economy?
Could we be reaching the end of the road for the API economy?
We've grown used to the idea of open, public APIs. It's easy to quickly bring a Swagger definition or a REST endpoint into an IDE, and quickly start using code someone else has provided. Those APIs are incredibly useful, giving us access to services that would have taken months or so to build.
That's a good thing, but it's also dangerous: what happens when that public API suddenly stops working? We don't have a direct relationship with the service provider, so can't really complain. Instead we're left holding the proverbial baby, shut out of a key element of our application, and struggling to fill the gaps in our code. There's also a nagging feeling that we've just been an experiment, our ideas and applications just fuel for someone else's platform -- to be duplicated and copied and turned into someone else's revenue streams.
It's a story that's increasingly common, as once public APIs disappear behind paywalls or are only offered to a provider's trusted partners. Applications that relied on them get a few weeks warning that they need to change, if they're lucky; in some cases popular APIs have been turned off without warning.
To a certain extent, these changes are a validation of the idea of an API economy. Closing off free access to popular APIs is a sign that companies see that they have value, that they're something that can be sold to developers as services. Public APIs are no longer loss leaders, they're part of a software and services offering.
It's a change that sadly makes sense. But by closing off access completely, and by limiting access only to trusted partners, companies are closing off a possibly rich avenue of innovation. So what can they do?
The answer is relatively simple: use an API management gateway.
API gateways are part of any well-designed cloud service. They're used to route calls to the appropriate service instance, handling both geographic routing and load-balancing, as well as responding to scaling. In a recent presentation at QCon in London, Microsoft's Azure team described how it uses a single API gateway to handle its many cloud services -- from storage to directory services and beyond, routing calls to appropriate service endpoints and handling complex payloads.
A gateway like this is an important element in API-focused service strategy. You can use it to handle user authentication, and then once user tokens have been exchanged, route calls to an appropriately provisioned endpoint. Is a user a subscriber, and at what level? If they're paying for a service, check how many calls they've made from their allocation, and deliver an appropriate error message if they've used their allocation so they can purchase more or upgrade a subscription to account for changes in user patterns. That doesn't mean returning a 200 OK message, it means delivering an appropriate and documented JSON response to ensure that applications are able to report errors to users.
That same gateway is also part of any API service provider's management tooling. It needs to be able to monitor calls, reporting on response rates and errors, as well as ensuring that throughput is maintained. A well designed API gateway should also be part of service automation, triggering scale-out deployments where necessary.
There's a lot that can done be with API gateways, whether you build or buy. They allow service providers to produce different classes of service for different types of users: throttling or limiting responses for free users, providing a fast channel for premium partners, even managing access to different APIs with different features for different groups of user, or for different apps. They're also able to provide a richer experience for developers, using tools like Swagger and other parts of the OpenAPI Initiative to make it easier for developers to use APIs in their apps, providing tools for IDEs to work with APIs. With Swagger, a machine readable API description can import API endpoints into your code, providing documentation -- and links to any subscription information.
While OAI might promise a better future, it's only part of the story. It's no protection against the sudden withdrawal of service. That's a problem that's better solved by policy rather than technology, for example by policies like Google's two-year depreciation for obsolete APIs. As Apigee CTO Ed Anuff points out: "Changes need to be messaged properly, and care needs to be taken in how you communicate."
After all, we don't want a repeat of what happened when Twitter closed off access to many of its APIs, when it realised that its revenue model was based on advertising. Suddenly a service that had become popular on the back of third-party apps and services was repudiating its original model, a change that upset many developers -- and closed down many innovative apps and services.
The problem is, of course, people. We're stumbling into a distributed computing API-driven world. In this realm, though the computer science and design patterns may be a done deal, the complexities of business models and developer relations are still issues.
Technological solutions like OAI and API gateways are only part of the answer; at its heart we need to find a way of helping business decision makers and a whole wide world of developers sit down together and build policies that work for both constituencies -- letting us build apps, and letting APIs and cloud services make money.
Let's hope that this isn't the end of the API economy, just an inelegant transition to a new phase. After all, evolution has always been messy.