Attended by thousands of developers, the recent Red Hat Summit in Boston featured hundreds of technical sessions on every aspect of cloud application development, deployment and operations.
Though the summit was dominated by talk of the company's new OpenShift.io online integrated development environment and Container Health Index scoring system, like all things cloud, everything boils down to API technology.
Manfred Bortenschlager, Red Hat's director of API market development, leads business development for API management and educates markets about the value of APIs. He came to Red Hat via its June 2016 acquisition of API management platform provider 3scale. During the Red Hat Summit, he sat down for an exclusive interview with SearchCloudApplications.
What does the term API economy mean to you?
Manfred Bortenschlager: Like with every other economy, in the API economy, you have suppliers and buyers, and they trade digital goods by using APIs as an interface. There are many businesses created based on API and different use cases -- not just to create monetary value, but value in other aspects.
API use cases include improving the process of data interchange with customers or suppliers. But we've had EDI -- electronic data interchange -- for decades. Is API technology just the logical advancement of EDI?
Bortenschlager: APIs have been around a long time from a technical perspective. The technology aspect of APIs is what people understand really well. What's now fairly new is that companies have the possibility to expose services and assets with APIs in a controlled and managed way. That's exactly where an API strategy comes into play. An API strategy is the bit that is fairly new to businesses.
An API strategy is not just about technology or API management, but also about the business mission.
Bortenschlager: Absolutely. You should not start with the technical perspective, but from the business perspective. A company can increase its agility by using APIs. You create a lot of modules, which you can internally put together much more quickly for more agility in reacting to changes in market conditions. [Companies can also] increase the rate of innovation. If you imagine you have internal services, you can expose them externally. There is a lot more collective brainpower than if you just use it internally.
Does that mean big changes for application developers?
Bortenschlager: It doesn't make a big difference, but a change in mindset, because we always recommend to think API first. When you design your applications, think how you can expose its services as an API.
Businesses deal with APIs that are developed internally, but also with many developed by third parties. How do developers know that a third-party API is any good -- that it performs well, is efficient, doesn't waste compute resources and that it's secure?
Bortenschlager: That is a great question, and it's one of the key challenges API consumers have. We recommend interactive API documentation, not just a static PDF file or HTML page. It's actually interactive. That means API consumers can play with the documentation, see the structure of the API, see the different parameters, what goes in and what comes back. They can insert various parameters, send a request against a live API, get a response back and see exactly what comes back. They also get an impression about the latency and the speed. Through that, developers get a very good impression about the behavior of the API before they implement a single line of code. It's an efficient way for API consumers to understand the API.
Businesses that develop APIs for their customers have to deal with the nightmare of supporting multiple versions of an API simultaneously. What is your recommendation for managing that common and complicated scenario?
Bortenschlager: It's a challenging scenario that happens all the time. It's impossible to have an API with changes that never break. It's impossible. That's just the nature of it. What's important is to communicate changes very well and far in advance. With an API management solution, you know exactly who is using which API, and you get statistics about them. If you know that you are going to change a subset of your API to a new version, you can target the communication to those developers in advance.
Manfred Bortenschlagerdirector of API market development, Red Hat
What is the single biggest mistake that application developers and architects make in using API technology during the development phase of a project?
Bortenschlager: One thing that's difficult to get right is API design -- in particular, the right granularity. What I mean by granularity is that an API could give you a lot of data back; a lot of values, which are potentially unnecessary; or just too much data. If you are serving a mobile app, this could be too much payload. On the other end of the scale, you could have an API that gives you too little back. This means that an API consumer would have to issue many API calls. Getting this balance right is tricky.
How does a developer achieve the correct balance?
Bortenschlager: We always recommend two principles within API design. One is to design for simplicity, and the other is to design for flexibility. With simplicity, we try to understand what your customer's most important use case is and serve that case well, even though it may be an API call that is a bit bigger. At least you serve all the key use cases very well. And at the same time, break down the API into more fine-grained elements so that you design for flexibility so that the API consumers can stick together the various API calls the way they need them.
How should you handle API security threats?
Red Hat launches on-premises containerized API management
Red Hat OpenShift.io launches browser-based app development