The State of APIs with Postman’s Ankit Sobti
Postman CTO Ankit Sobti dives into a state of application programming interfaces (API) report that suggests the rise of generative artificial intelligence (AI) is about to transform the way APIs are designed.
Transcript
This is Textron tv. Hey guys, thanks to the throw. We're here with Anki sot CTO for Postman, and we're talking about a new report that they have out about how AI is going to impact the way we design APIs.
And while we've been designing APIs pretty much the same way for as long as I can remember. So I'm welcome to the show. Thank you.
Thank you for having me. Really excited to be here. So walk us through this a little bit.
How will AI change the way we think about API design? Because, you know, sometimes when I read everything there is out there, I think if I just magically think it somehow or other it's just gonna get created. But I don't think we're quite there yet.
But, um, where are we on this adventure and how will AI apply? I think that's a really good question. And you know, one of the big things that we see with respect to these large language models is that these are models that are trained on historical detail, but the way that, you know, all of these systems are now interacting with the real world is happening through APIs.
So one of the ways that we like to think about it is, you know, like the, A bs can be seen as the hands and legs that put AI's thoughts into action. Uh, so the way that you're responding to a real world situation where information, if the is instructing some system to do something, all of that becomes APIs. And when you combine these together as geni combined with APIs, just allows us to have more sophisticated, nuanced interaction with human than machines.
Now, how that, you know, applies to API design is that now, you know, uh, one of the conversations that I've been having a lot of executives is kind of like the moment that you saw with search when a lot of websites that were not being optimized for, you know, uh, just crawling eventually started get disappearing in the world. And I think one of the things is, as we are at this inflection point of how, uh, you know, we are interfacing with all of these different technologies, if conversationally whatever form that takes is how we interact with the systems. The companies that do not have ABIs or have poorly designed ones, the ones that are difficult for AI to crawl, become increasingly invisible in that world.
Especially where AI driven interactions are the main norm. I think one way to think about it is that you are now designing a PS for two types of consumers. There is designing for humans, and then there is designing for the AI bot set of consumed the APIs as well.
Mm-Hmm. In some ways that's kind of just how we design content today, right? It's sometimes it's for the machine and sometimes it's for humans.
And it all depends on where we think the primary audience is gonna be. What do I need to know about API design to keep it in mind for the generative AI platform? Are there procedures, techniques that I should always implement?
I guess, you know, is there some sort of SEO equivalent for APIs for Gen ai? I think it's a little early, but I think if I had to go, uh, go at this from a more philosophical point of view. So there is the aspect of designing APIs for humans, which is, you know, like better documentation, making sure that there are more examples, making sure that APIs are discoverable.
And from a machine readability point of view for AI to read those APIs, I think you have to think about how you structure your metadata and make your APIs easy to consume. Because if the APIs are inconsistent, they have, you know, different design and just you end up hitting these dead ends and you're not. And if the AI bots cannot figure out where to process and go with your API, I think that's where you start seeing drop off and choices become more important.
That point of view. I think a second big factor I feel is that also with respect to the way that we consume a p and with, especially with respect to like large data sets, I think with AI you are looking at higher frequency automated interactions with also higher throughput data requests coming in. And I think the way that we design API is the way they think about bulk operations, sort of batch processing, just helping optimize those interactions become better.
And if I don't do this, it seems like, um, maybe unlike human developers that might get annoyed, but they'll try to work through it. Um, the AI bots are just gonna move on to the next API that is simpler for them to use to perform the same task, right? 100%.
And that's about, uh, referencing back to the point I made earlier, is that's where you start becoming more invisible in the world where you just don't have well designed APIs to just appease the AI bots that are and the more difficult you make it to consume. And that's where I feel like your, uh, observation around SEO optimization is kind of critical because it is about, again, uh, easy understanding, easy pathways, machine readable metadata, all of those factors play a critical role. We have all discussed in the past, the notion of the API economy is this whole thing about to move into steroids in the age of gen ai because all these things will be happening in split seconds.
Yep. 100%. And I think, uh, you know, I mean even if I go back to like, so we did the state of the API I report, uh, you know, this time and one of the big things that's come up is, uh, this a rapid increase in API monetization.
You know, we see from our respondents more than 62% of the, uh, you know, respondents and now working with APIs that generating income, 25% of the companies have APIs are driving over 75% of their company's revenues. And E ps have already become fairly mainstream when it comes to becoming now strategic revenue generating products. And I think when you have AI bots interacting with them and you just have a proliferation of more APIs that exists in the world.
One counterpoint, actually one additional point that I would say is that with the rise of, you know, gen, uh, used for, uh, coding and with the programming becoming more commoditized with the, with ai, I think what we are also seeing is the rise of more APIs getting created faster and there are more and more a p endpoints that now exist in the world. Um, because of that, Will we get to the point where we're using gen AI to design the perfect API in itself? And maybe we can create something that feels more like a virtuous cycle where we're using AI to create APIs for ai.
Uh, I, I do agree and I think there is a part of knowing, you know, I think a big part of API design is actually thinking of the interface part. It is thinking about the consumer and a deep understanding of what problems your consumers are trying to solve. How are they solving it right now?
And, you know, what problems can you solve for them? And I think that's where the design element comes in and where the human creativity output comes in. So that, yes, we are quite, I agree that it's easier to get the APIs out there faster, but in terms of what is the right API, what's the right abstraction?
How is it solving a legitimate problem and how it connects to the revenue generating opportunities for your business itself. All of this, I feel, requires that human creativity to shine through in the way that we think about APIs. Do you think that we might be ripping and replacing APIs more frequently as we go along in the age of ai because the, the overall pace of change will be that much faster?
I think maybe, but I think APIs are one of those things that, you know, are always difficult to change because these are contracts that exist between different systems. And the more frequently that you change these contracts, the more difficult, the more consternation and frustration it creates in the minds of the consumers. And I think, you know, even though maybe I would say more APIs getting created faster would be there, but I think change management when it comes to APIs is fundamentally, uh, you know, difficult and it's, it requires thoughtful, methodical thinking of how you are gonna proper propagate that change.
Mm-Hmm. One of the things that we have seen over the years is, uh, emergence of rogue APIs, zombie APIs. Um, do you think that maybe we can find these things more easily and uh, maybe prevent them from being abused by bad actors, but I think part of the issue we have out there is sometimes we get a little API happy and then we forget about 'em.
Yeah. Uh, I mean, we see that all the time. Like with some of the companies that we work with, you see that, you know, 5% of your public API portfolio generates like 95% of the revenue or usage, but most of the time, you know, actually goes in managing those, uh, 95% of the user of the APIs that you have out there.
And obviously that leads to more security vulnerabilities potentially, or, and I think a big part of that is still coming from this idea that pe you know, when people are putting out APIs, they're like, okay, we're gonna build it and you know, so let's build it and they will come. But I think what we have found is that the best API teams fundamentally collaborate early and collaborate often with their customers and prospects and users who understand what are the APIs and what form factors that they should take and how they should design the A ps to support that. And I think that rapid collaboration with your consumers and customers becomes a very integral part of how you think about a PS.
And to your other point, I think there is increasing proliferation of tools and systems that allow you to understand or observe how your APIs are being used, not just for performance or uptime, but also for usage patterns. Who are the consumers? How are they consuming it?
What combination of endpoints are they calling? Are there certain APIs that are not being called and that allows you to plan the structured change management that you want to deliver against api? Mm-Hmm.
One of the things that kind of drives people crazy sometimes is folks designing the APIs will make a distinction between APIs for internal usage versus external usage. They'll take much care with the external one and the internal one and kinda, you know, it's a best effort. Nobody goes out of their way to deliberately make a bad one, but they, you know, things happen and yet three months later somebody will turn around and expose that internal API externally and, you know, all kinds of chaos.
We'll see. Yep, 100%. And I think, I mean, some companies do it in a more structured way where, you know, like every a BI is designed for externalization, but I think a part of us, as you know, uh, platform pro provider in the a b space, I think what we are also doing is making it easy for or easy, much easier for you to actually have the same level of rigor that you have for externalized a ps also for internal worlds, how you document, how you illustrate the a PS consumption, how you test, and, uh, a big part of Gene I and in Postman as well is also about of optimizing some of those workflows so that you are just able to do all the effort and care that you take for your external APIs to also be in, uh, you know, in a far easy way to actually do it for your internal APIs as well.
Two, we have more at risk as well in the age of APIs than ai. And I'm asking the question because a lot of the times if I go build an LLM or RAG interface or whatever and I customize it, I'm gonna expose that to somebody else through an API and if that's not secure, um, yeah, all kinds of data could be exposed that previously I might not have thought whatever get exposed. So do we need to be more careful about how we design these things from a security perspective?
100%. And I think that comes down to a not putting too many APIs out there, but you do not know, and you're not just building it, assuming people will start using it. You are including feedback and learnings from our customers and users early on in their design process itself.
But the second part is also designing for a robust security and governance, uh, system around your APIs. Because not having the right authentication protocols, not having great limiting, not having throttling, uh, but doing all of this in a more methodical structured way means that both your human users and AI agents can access the data securely and uh, responsibly. I think everybody will nod their head and say, well, of course we need well-designed APIs and then, but I'm not sure everybody understands what that means.
So what is the definition of a well-designed API, what characteristics should it have and what should people be looking for? I think I like to always call it as APIs. Uh, the best a p are the ones that get used.
Uh, and I think that's an important distinction sometimes to make. Uh, but the second part I think I would add to that is it's also about, uh, meeting the customers and their needs and rapidly evolving it to them. And I think a big signal for, you know, there are a few metrics that I've seen companies adopt over the years is the kind of experience that they're having with their API like, uh, you know, bounce state, which qualifies as, you know, somebody coming to your API and not being able to make a single successful call.
Some companies measure the time it takes to make the first calls, but I think more nuanced companies even measure time to value, which is the equivalent of how much time does it take for a, a new user or a customer to come in to actually be able to successfully integrate what you have created into their workshop. And a more nuanced version of that being time to delight or time to wow, which is something that you really optimize for by designing not just the API itself, but also designing the user experience of how somebody experiences your a p. And I think both of these factors become very critical in the way that your APIs get adopted.
And again, to come to my original threshold of an API that actually gets used and used at scale. Is there a distinct difference these days still between the way we design APIs and build them versus the ways that we manage and secure them and consume them? Or is all of that starting to converge around a consistent motion that maybe gen AI will enable or streamline for us?
Uh, I think so. I think it's, uh, you know, more and more companies that we see are now thinking about EPF first development as a standardized practice practice, and then there are, you know, centers of excellence or teams that are guiding how EBI should be treated as core products from the outset rather than something that is as an afterthought. And I think that transition is happening in the industry, uh, and the assertion is that ai, gen AI helps you make it that transition faster because what you're fundamentally looking at is that, you know, even though we might be getting a little bit better at, you know, meeting the functional requirements of the A ps uh, you know, performance, scalability of time, but in terms of how we design user experiences in terms of how we design APS for discoverability or consistency and, you know, some of the metrics that discussed in the last question, I think all of those factors become essential towards the way they think about a PS.
But end of the day, you know, you're designing a EPS per consumers if you do not incorporate them, them in your design process, in your thinking process. And also, and you know, when people start using it and how actually observing and understanding how they're consuming it, yes, your APIs will eventually, you know, not be as successful as they, So at the end of the day, you've been doing this for a while, are there things that you see people doing in terms of the way they design APIs that just make you shake your head and go, folks, we need to be better than that, and are they about to be left behind in the age of ai? 100%.
And I think it comes on to the level of attention of detail, and this just comes under the fact that the api, if the APIs are not popular or they are not, or, and by popular I mean used or if they're not easy to consume by humans or by ai, yes, you do run the risk of your business itself becoming visible because I think we are at the task of user interfaces, even for consumer products just changing is are evolving from where they're, and I 100% agree and I think, you know, if you have to even visualize a world, you know, the, of Joaquin Phoenix and her talking to Scar Johansen on his, uh, you know, device and then, uh, but you suddenly have to like pop up your phone and passing OTB with, just to find out my bank balance. Suddenly that current experience of like how you actually authenticate your a PS changes, and I think that's where the opportunity exists for how you design your APIs. How do you design your UPS for even the changing interfaces that we would imagine coming up, um, in the not too long, not a distant future.
Right? Folks, you earned it Here. They say the devil's in the details.
And I think when it comes to APIs, there's no better example. Hey Anke, thanks for being on the show. Thank you.
Thanks for having me. All right. And back to you guys in the studio.