After Dion Hinchcliffe gave the keynote speech at API Strategy and Practice Conference in Austin, Tex. last November, InfoQ sat down with Dion to get his vision for the direction of Web APIs.
Based on a decade of in-depth experience, Dion explains how the history of REST and simple design influenced the ultimate popularity of web APIs over web services. As businesses adopt web APIs more broadly, Dion explains the past and present, and hints at the future of APIs, platforms and networks.
InfoQ: Can you introduce yourself and tell us about your background and your main activities?
Dion Hinchcliffe: I’m currently chief strategy officer of 7Summits. We provide developer communities for things like APIs. I also do a lot of research and analysis in the digital space and write for ZDNet and other online outlets, and I've written a couple of books in the space as well.
InfoQ: You started researching web APIs about 10 years ago. What triggered your interest initially?
Dion: The first time APIs really got on my radar is when the developer community really started to talk about REST as opposed to the more traditional heavyweight web services.
The data was just beginning to emerge that the simpler more web-oriented APIs were more popular, easier to to use, and worked better with development tools and technologies and even regular business applications.
At that point, Amazon was publishing data comparing the popularity of SOAP vs. REST and it became clear that the old world of web services wasn't very popular at all and that something exciting was happening around web services on the web, which we now call APIs.
InfoQ: Looking at your original vision for Web APIs, what are the most striking differences with where we are today?
Dion: I've been very gratified that the API market and the developer journey has been a lot like what we expected it would be, about lightweight APIs. I think I expected more innovation. We saw things like JSON emerge as alternate ways to create even lighter web services.
I think I expected there to be more tools support than what was initially being required which is kind of the point anyway, but up until that point, platforms like Eclipse where doing a lot of the heavy lifting web services, providing stubs and so on, and now you see that wasn't required or needed.
Perhaps the biggest surprise was around the subject of security and despite early predictions, those initial simpler models for APIs have actually proven pretty resilient and able to be secured as almost anyone requires, whereas I had predicted a whole security industry.
InfoQ: What is the level of maturity on Web APIs with typical organizations?
Dion: What's interesting about technology is that adoption is so unevenly distributed. You can't really say that there is a typical organization, and the early adopters, like with APIs, are often very early.
But I think it's safe to say that the average company is fully aware of APIs and uses them, but not strategically. API divisions or API departments are still a novel feature of leading technology organizations or startups.
InfoQ: What are the most valuable use cases for Web APIs for those typical organizations?
Dion: Top use cases include enterprise application integration, workflow, mobile applications, third-party integration of cloud services, and now it will be in the very near future Internet of Things.
InfoQ: You frequently talk about the importance of open APIs to support the digital transformation, but aren’t internal APIs powering mobile apps, web apps and other UX finally more critical for companies?
Dion: Every company should be using their own dog food and be the first customer of their own APIs, which means that most APIs should be internal first anyway. And certainly it's how companies develop organizational maturity with APIs by learning how to produce and consume them inside the organization.
But, as what's outside moves inside and inside moves outside, we are seeing that APIs need to be ready for anything, and can be used in any way, as services are remixed and digital experiences are created out of many formerly disparate feeds and APIs.
InfoQ: Open APIs have helped make APIs popular but recently some companies like Netflix and Twitter have started to shut them down and many public API programs are competing for the crowded mindshare of developers. Do you see a growing trend or something marginal?
Dion: I hope that they are the exceptions that prove the rule, but there is a growing belief that APIs are very beneficial in earlier stages of a company’s growth, but can become a drawback when they become a leader.
But you can just as easily point to counter examples, like Expedia, eBay, and Amazon, for whom APIs are primarily how they do business, so it’s clear the jury is still out and certainly APIs are essential for early-stage growth.
InfoQ: API management vendors have mainly positioned themselves as gateways between the legacy IT assets and the new user experiences, including Amazon with its new AWS API Gateway. On the other hand, cloud-native companies such as IFTTT, Uber or Twilio are building distributed API networks, disrupting traditional businesses. What is the right metaphor for a traditional company to envision web APIs?
Dion: I think it's both but it's much more the latter. It's a prerequisite as a gateway or you can’t access the ecosystem. So you can't really have one without the other anyway, but once you have access to the market, the API should be designed to encourage and foster a healthy and growing digital ecosystem. So they are not mutually exclusive in my mind.
InfoQ: Do you think that companies will eventually need to build one custom API per user experience or channel of interaction, like Netflix is doing now, or that most companies will be better off with a one-size-fits-all API?
Dion: I'm always cautious about one-size-fits-all for anything, especially on the complex intersection of digital technology and human needs. Many companies can certainly start with a single API but the growth and maturity of their products and external customers will soon teach them if a single model is the right approach. I think often a more nuanced approach is appropriate.
InfoQ: How important is REST to the overall value and success of a web API, compared to RPC variants such as the recently announced gRPC project by Google?
Dion: What's clear is that REST has become foundational as the fundamental model for open APIs because it is so aligned with how the web works natively. But it can never be the answer to all scenarios. especially for things that weren't initially anticipated in the design of the web, like video, real-time communication, and other more modern scenarios.
I think you use the right tool for the job, while staying as close to core standards as you can.
InfoQ: There has been an ongoing debate about whether or not PaaS will eventually emerge on top of IaaS and be widely adopted. What is your opinion on that?
Dion: The more constrained any design is, the fewer scenarios can be applied to it. IaaS and PaaS are no different in this regard.
IaaS is applicable to a great many more scenarios, virtually all of those in computing and networking, while PaaS has a much smaller domain and so it's back to the framework argument, the larger and more complex the framework, the more constrained in solution space it inherently is.
So, IaaS will always be more widely used and broadly applicable than PaaS. It is clear that there is a large market for PaaS. I expect both are going prosper but one will always be larger than the other.
InfoQ: You talk about citizen developers as business users capable of doing basic development with the proper tooling. Do you think this has become a realistic way for companies to develop software solutions?
Dion: I think we are now on the cusp of this being ready for the average organization. Leading companies have done this for many years, since there have been APIs actually. As soon as APIs appear, these kinds of tools appear. This is amazing.
The model for now, beyond very simple event driven applications is for citizen developers to build user experiences and simple application flows and IT helps by filling in and completing the application logic. It’s a very exciting space, that there are enough evidence that indicate that we are in the early stages of the blossoming of citizen developer as a real entity, again made possible by APIs.
InfoQ: Will business users want to provide or consume APIs per se, or will they need less technical paradigms such as connectors, spreadsheets and forms?
Dion: I've been gratified at the broader understanding of APIs in the non technical user community, but we haven’t really seen an effective metaphor that can fully replace it.
I think users understand concepts like simple “apps" as an understable unit of functionality and data, so in today's low-code environments, data sources are often conflated with the apps that provide them, such as getting the forecast from Weather.com as opposed to Weather.com API which is where the data really comes from.
These days, there is a general understanding that apps are data source when it is the API that really does the work, so I think it will all work out.
InfoQ: You’ve talked a lot about the power of distributed networks and platforms. How important are APIs in this regard? Are they strategic, tactical or a mere technical aspect for a company?
Dion: So, I was talking to API pioneer John Musser about this topic this afternoon here at the conference and that APIs themselves are still critical to achieving the highly decentralized systems we are talking about that are required to create successful digital businesses.
But that meta-concepts above the API level are now growing in strategic importance and are becoming a central study as much as the APIs themselves.
I would point to the work of John Hagel's team at Deloitte on their work at ecosystem patterns to show that there is an architecture level one major step above API architecture.
This is something we have really understood for three or four years now and that's where the strategic discussion is really moving.