Following the “I love API” conference in San Jose, InfoQ had a chance to speak with Ed Anuff and Marsh Gardiner from Apigee. After an IPO in April that created increased awareness for both Apigee and the API industry in general, the company is now moving API technologies into new areas by understanding how applications are developed and how people use APIs.
InfoQ: Apigee has grown significantly over the past few years. What technology does Apigee offer to API developers and their teams?
Ed Anuff: Apigee's basic focus is API management. It's all about making it easier for developers inside and outside their organization to use APIs. There are so many aspects in addition, like API design, that we cover with our API Studio. We help developers take existing systems of record and turn them into systems of engagement to support digital experiences.
Marsh Gardiner: That's a big part to figure out how to connect the different types of data to different types of applications. We do a lot of thinking about backend systems and how applications are developed (mobile apps, IoT, etc.).
InfoQ: What level of API adoption and maturity do you see among your large enterprises and SMBs customers?
Ed: So, the thing about APIs that is different now is that everyone is using APIs. I don’t know if they fully understand APIs, REST and all the subtleties though. The question is now how much they are using them. There is an explosion since the last four years that I've been here.
Companies were thinking about doing APIs and now they are doing it. That doesn't mean they are experts of it. It's like for databases. So that's the next big thing, people are going to want to understand how they design APIs and how they manage the API lifecycle.
Marsh: Our larger customers often have very significant sunk costs around their systems of record (SoR), and they are trying to figure out how to expose the data in the SoRs that to apps, the systems of engagement. Big companies often suffer from more inertia as well, so it can be hard to get them to think differently about how APIs affect their business.
InfoQ: At your conference, Apigee took a strong position in favor of the API design-first approach. Can you describe what it means and if there is a significant shift happening right now from API code-first?
Marsh: We ran into a certain kind of challenge with API development ourselves. Five years ago, we might write an API specification in a Google Doc, give it to the development team, and maybe get something back that was more or less matched the design document if you were lucky.
There are a few problems with that: you are not going to cover every possible detail in your design document plus things will be open to interpretation during implementation. Most importantly, design has to evolve so where you start from is just a best guess as you move into implementation.
Saying its design-first is a slight misnomer because design-first suggest that the design phase ends. The beauty of this contract-based development process is that the design and the implementation can iterate in parallel. API design never stops until you're satisfied that you have a version you're willing to live with for a long time and can start inviting others to start consuming it.
One last challenge with the old way was that a client couldn't build against those services until they were stood up as a service—but if you have a formal specification like a Swagger document, that can drive a mocking service and enable client- and server-side development to happen in parallel.
InfoQ: You announced API Studio in beta last May. Can you describe what it offers and how it compares with the open source Swagger Editor?
Marsh: API Studio brought together a number of open source projects we had contributed to the community, such as the Swagger Editor, but it added something you couldn't do with a server-side component. Because the Swagger Editor is a browser-based client, in order to have a proper mocking you had to have a proper server-side component.
Ed: the Swagger Editor is open source and Apigee was the main developer of it. It uses Node.js and the backend and not everybody wants to install it themselves, so the first thing was to setup a hosted version in the cloud. Lots of good features could then be added like a mock service.
Marsh: Another key feature is the ability to collaborate on an API specification with others.
InfoQ: WADL is used in Apigee API Console to provide an API contract and Swagger is the basis of Apigee API Studio. What is your plan moving forward in term of API languages support?
Marsh: The Apigee API Consoles predate Swagger. WADL was a great format for those at the time, but we've put all our recent efforts into trying to create a standard around Swagger.
Ed: There are other people doing good things like RAML and API Blueprint, but we want to focus on one and try to do it well. There will always be ways to import/export from different formats.
InfoQ: Apigee has been an important contributor to Swagger so far, especially to Swagger Editor. Will the recent change of Swagger sponsorship to SmartBear, another API solution vendor, modify your level of contribution to the project?
Ed: There has been a lot of activity to create an open foundation around Swagger and we are a big supporter of that. This has resulted in the recent launch of the Open API Initiative (OAI) under the Linux Foundation.
Marsh: We will continue to contribute open source code to the community based on top of the Swagger specification. We firmly believe in the Swagger specification as the format for the future.
InfoQ: Ed, you originally created the technology behind Apache Usergrid. How has this project evolved over the years and how can it help API developers?
Ed: Usergrid is a backend as a service, mainly for mobile developers but other developers can use it too. It provides very scalable identity and data storage and other services like push notifications. Apigee uses it in our products but it is also open source. We brought it to the Apache Foundation and it has graduated from the incubator as a top level project.
A lot of developers are using it, contributing to it and it has evolved a lot. It is based on Cassandra and the development team has also added Elasticsearch to it.
It has also become much more scalable and can now do more than 10k requests per second and it's something that API developers can benefit from because it's all based on REST APIs. We're very excited about it and at the conference we had a full room for the Usergrid session.
InfoQ: Marsh, you gave a talk at the conference with Martin Nally on Pragmatic REST and the key differences between service-oriented and data-oriented. How different is this from REST as it is commonly practiced, and from pure REST principles?
Marsh: The big difference is that pure REST has a lot of constraints. We're taking a much more pragmatic approach. For example, we aren't taking the position that hypermedia must be the engine of the application state. We don't see the need for HATEOAS at this time, but we certainly do see a lot of benefits in REST, including hypermedia.
Behind it, there are two personas. Service-oriented is a natural way for developers, who already think in term of functions, to expose those functionalities. But being Data-oriented is to think about how that data itself is being represented and in the relationship between entities. The best way you can see how we put this into practice into our own products is in Usergrid.
Ed: Hypermedia is really an unrealized ideal but it’s also the only way we could do API without governance. Any time you do governance, you do SOA. I understand why people want hypermedia because everything you need to know is in the API. Without hypermedia, what you need to know is in documentation (security, governance, etc.). That's why people like it, but it might not be possible to fully realize it.
Marsh: The way I see it, hypermedia-driven APIs are a kind of “just-in-time contract.” This is a fundamentally different way to view the world than contract-driven. And it's not that one or the other is better, it has to do with different situations.
Ed: Zetta.js is our open source IoT API software and that has a very robust hypermedia API for controlling devices. It’s a good example of what hypermedia makes possible.
InfoQ: How does Pragmatic REST deal with versioning?
Marsh: In the talk, Martin's point was that it’s better to put the version in the subdomain. You see the separation you need between breaking contract but without polluting the path itself. People often put it in the resource because it gives them wiggle room to know that they can make changes in the future… but if that's the best reason for it, then maybe that's not worth doing.
InfoQ: Today, API developers mostly rely on HTTPS for confidentiality, and HTTP Basic or OAuth 2 for authentication. Do you see new security schemes such as JWT/JWE/JWS, HMAC and digital signatures taking a bigger place or only providing niche solutions?
Marsh: I wouldn't count JWT as an alternative to OAuth—it improves OAuth. It's a nicer way of dealing with tokens in that they can be independently validated and can contain useful information.
Ed: JWT is a big deal for scalability so we are big fans of that. We are shifting over JWT tokens.
Marsh: HMAC signatures have been coming up more often over the last year, particularly from enterprise customers who take security very seriously. They want to encrypt the payload to ensure its integrity. But that adds friction and increases the barrier to adoption. Sure, maybe you can solve some of that with SDKs, but now you've got N+1 problems, where N is the number of language you're going to support and maintain. Every time that HMAC signatures come up, I challenge to understand WHY it is really needed and whether it's worth the pain it will foist on developers.
InfoQ: How does your new Apigee Sense product help API teams on the security front?
Ed: With your web site, people would use screen scrapers and bots to steal your content or maybe try to attack your web site. Now that's all happening via APIs and so Sense tries to solve that problem for APIs. It uses predictive analytics and it’s something we've been doing for a while. We've acquired a big data company called InsightsOne. The idea is that you can use machine learning to figure out if however is calling the API is a legitimate user, even if they have the right credentials.
Marsh: With Sense, we are way beyond network firewalls.
InfoQ: What are the main needs that you see in terms of API testing today, and how does your new API Health service help?
Marsh: We think that any modern API today needs to monitor both synthetic and organic traffic. So at the conference we talked about API Pinpoint, which gives you visibility into your organic traffic and its performance end-to-end. But synthetic tests are just as important to the API lifecycle and can tell you whether the latest build candidate is breaking your contract and can also be used to validate performance of your service at a known and regular interval.
InfoQ: What is the future of APIs from a technical standpoint? Will real-time, webhooks, lambda, and microservices fundamentally change how we develop APIs tomorrow?
Ed: I think webhooks has been the biggest thing that no one talks about in APIs and that has been the most exciting thing. You look at webhooks in GitHub and Slack and a whole bunch of other places, and it’s now the way that people make SaaS extendable. I think it's bigger than microservices.
I used the term “two-way APIs” to describe that. Microservices is a one way API, but with webhooks the service can call other applications. A lot of people are discovering webhooks because of Slack.
Marsh: One interesting aspect of webhooks in my opinion is how it turns authorization upside down. With traditional APIs, OAuth is the common standard, but with webhooks, you call into the system, and in order to validate the origin of the request, a shared secret, like an API key, is common. It's up to the receiver of the webhook to validate that token.Ed: Everyone is talking about microservices, but I don't know that everyone agrees on what they are, but everyone is using that term like REST. As I've said before, "If you like microservices, you are going to love SOA!"