Ryan talks with Sterling Chin, a senior developer advocate at Postman, about the intersection of APIs and AI. They cover the emergence of AI APIs, the importance of quality APIs for AI integrations, and the evolving role of GraphQL in this new landscape. Sterling explains how some organizations are shifting toward an API-first development approach and talks about the future of data access in the agentic era, where APIs will play a crucial role in AI interactions.
Postman is an API development platform that lets developers prototype, document, test, and demo all their APIs in one place.
Postman’s cofounder and CEO recently wrote about the rise of agentic AI.
Find Sterling on LinkedIn.
Shoutout to Stack Overflow user Knossos, who earned a Lifeboat badge by answering What is the difference between TextView and TextViewCompat.
APIs, AI, GraphQL, REST, gRPC, API-first, Sterling Chin, Postman, technology, software development
[intro music plays]
Ryan Donovan Rapyd Cloud, a high performance managed WordPress hosting for dynamic websites with high traffic spikes. Forget hosting hassles with autoscaling, 24/7 support, and top-notch security. Use promo code stackoverflow for 25% off on annual plans at rapyd.cloud.
RD Hello, everyone, and welcome to the Stack Overflow Podcast, a place to talk all things software and technology. I'm Ryan Donovan, Editor of the blog here at Stack Overflow, and today we're going to be talking about the intersection of APIs and AI. My guest today is Sterling Chin, Senior Developer Advocate at Postman. Hey, Sterling. How are you doing today?
Sterling Chin Great. Thanks for having me, Ryan.
RD Of course, of course. So at the top of the show, we like to get to know our guests, figure out how they got into software and technology. So how did you get to where you are today?
SC I transitioned in my mid-thirties. I was in construction, transportation, and logistics. A good friend of mine had suggested that I look into tech. He was a software engineer. And so in 2016, I quit my job and I went to a boot camp back in the day and made my transition into tech, and since then, it's been an absolute blast. I've been playing video games and I've been around tech my entire life but it was nothing I ever went to college for, and I will be forever grateful for my friend who convinced me to go back to school.
RD Well, there is a similarity. You're in construction, you're building things, you come to tech, you're building things.
SC It is. The parallels are enormous and I found that a lot of the skills that I had leading construction teams, various projects, and doing that kind of stuff has suited me well moving into tech.
RD Okay, so today we're talking about Gen AI, which I'm sure our listeners are a little bit sick of, but we're going to talk about it from a different angle. Obviously a lot of the Gen AI resources are accessible through APIs these days, so what is the sort of story around that? What are the concerns? What are the benefits? What's going on with that right now?
SC Well, the only news cycle for the last two years has been Gen AI, but the difference for me and looking from Postman is that the majority of us are interfacing with AI through an API. Yes, I'll use ChatGPT or Claude or something, but when we are really building and integrating with AI, it's all through an API. And so my focus has been let's make sure that we get your APIs ready for AI integration. On Postman in the last year alone we've seen a 73% increase in AI API-related traffic, in just this year alone, and that's pointing to a significant increase. There's a lot of people who are trying to integrate with AI in those ways and it just goes to show where the industry is going. AI can do really great things, but on its own, it's okay, but once it's integrated with our products, with our features, that's when it really becomes powerful.
RD Everybody is figuring out how to integrate AI into their products. We mostly talk about how to mitigate whatever prompts and resources, but there's a lot of data being transferred in those APIs. We're asking those APIs to do a lot of heavy lifting. Do you know sort of the scope of some of those APIs and what they're lifting?
SC APIs, the various protocols, are really good at certain things. REST is still the standard, the de facto standard, and so AI is still using just REST to get data and try to transform it and make it work for them. But AIs really need structured data, and so I'm finding myself leaning more heavily towards GraphQL as a way of transporting just the exact data in a format that they can use, and that structured data is so much more vastly important now than it was a couple years ago.
RD It's interesting that you bring up GraphQL. That's something I first heard about about five years ago here on the blog and I recently saw something where somebody was saying that GraphQL is dead. That doesn't seem to be the case. Why do you think that GraphQL is more important now?
SC I saw something similar where people have said GraphQL is dead. I've been a GraphQL fanboy from pretty much day one. I use it in my own personal projects. I've used it in past companies. The reason why I think it's more important now is that if you can open up introspection in GraphQL, then as we get to the next phase of this AI era which is going to be the agentic era where we have multiple agents trying to interface together, if they can introspect and look at the API and say, “Okay, here's the data I have access to. Let's pull just what I need,” then it's going to make the agentic era much easier. Once you get to multiple agents trying to get data from the same sources, as an engineer it's going to be much more difficult to keep up with what AIs need. And so just being able to say– I’ve used the term and I know this is wrong, so GraphQL people don't hate me on this– but I love GraphQL because it feels like the graph is a data lake. It's just there, all my data is there and I just have to ask for what I want. And so in that case, that's why I think GraphQL is going to be more important as agents come up. This is hopeful thinking on my part, but like I said, I love GraphQL. I think in the long term, it has a much bigger role to play in the agentic era that's coming up.
RD That is an interesting comparison to the data lake because it is sort of one point of entry to all the API fetches and you sort of parse it down using parameters. That's my understanding of it, is that right?
SC Yeah, exactly.
RD So we were sort of chatting before this about the increased load that the AI APIs are taking on. What's the scale of that load and are there comparable APIs now doing that sort of work?
SC Well, with AI APIs, they can handle so much more data than previously. Every new model iteration that comes out whether you're 3.5 now to 4, 4.0, o1-preview– that's just OpenAI's models alone– their throughput and what they're asking is that you have to be able to get more tokens to them so you can get more tokens back. And the larger the models, the more important it is that our APIs are ready to handle that much throughput. When it comes to what we're seeing at Postman, we've seen drastic increases in load when it comes to how much is going through your APIs. The other thing we're also seeing is that a lot of people are building APIs faster than ever before and there's a few concerns that I have there. One of the things I talk about– I have a talk that I've presented that's entitled, ‘You Can't Do AI Without Quality APIs.’ It's something that we've coined here at Postman. I use the analogy that you've got robots building robots in a robotic factory, and that's kind of what we're doing right now. I bet I could almost guarantee that the engineers who are listening who are building their APIs, they're most likely using AI tools because APIs are being built now in under a week. That's unheard of. That's faster than ever before. So the ball has continued to roll and has just continued to get larger and larger. So I worry that the APIs are being generated by AI, so it's like asking that robot to build the robots in a robotic factory. You need to have a good blueprint, and that's where Postman really comes in. That's where we really try to help you help guide the users. We have our own AI assistant inside of Postman, but the main goal is to make sure that your AIs are able to deal with that additional throughput, that additional load. So we have load testing, we have monitors, we have mock servers where we can mock data for your API so that you're not using those tokens necessarily, or you're not hitting your production. And then we also have tools like Collection Runner in Postman where you can simulate those types of workflows and you can do it at scale. So you can run them tens of thousands of times a second to really test whether your APIs are ready for that AI integration.
RD That's a great point. I remember at my last job working on some partner API integrations, some of the product folks would just give away APIs that were part of our product but weren't part of the set we gave to clients and we were like, “Oh no, we’ve got to talk to folks and make sure we have capacity, make sure everything can handle this.” And that was definitely a scramble that the product folks didn't think about.
SC The move towards API-first is huge. As a product developer and as a developer having been in product and engineering and been on product on that side as well as now doing developer advocacy as I have been doing, I get to talk to a lot of people and the transition to move towards API-first is huge because now the API is no longer just a byproduct of your front end and back end but it's core to your business. One of the things that we've seen in our State of the API report is that around two-thirds of companies are making money from their APIs directly and 21% of companies are making 75% of their revenue through their APIs. So we're kind of moving to that era where your data is now more valuable than the UI. And when that comes in, again, now your APIs better be secure because you don't know what an AI LLM is going to be able to pull from it. It may test various response types, it may try to ask different questions of your data, it might try to pull more, and when we get to that agentic when it's no longer a human necessarily in the loop but it's just an AI, we need to have those guardrails ready for our APIs.
RD That is interesting because we just started a business providing data access to our sites through an API for some of these LLM providers. So that's obviously moving a large amount of data via API in a real time basis. Do you think that moving away from the sort of web crawl for data or taking these datasets, do you think the API access of the training data is going to be something that everyone should be getting it too?
SC I most definitely see that happening. We're seeing it happen with Reddit, we're seeing it happen with Stack Overflow. A lot of companies are now opening up their data stores and realizing that their data is more valuable to an LLM and to AI than anything else. The other side of this as we talk about GraphQL, if we're talking bits going faster, this is where gRPC or any of the RPCs, that's huge. That’s server to server, so once we get to that agentic era and now humans aren't in the loop, we're not trying to look at all of that. This is where I think GraphQL will also be limiting and REST will definitely be limiting, and where gRPC may actually really shine is where you're going server to server communication and that's going to be bits to bits. Geez, gRPC is so fast. At the speed that we're trying to transfer that data to an AI either for training themselves or opening up our data as a RAG database or a vector database for AIs to absorb and integrate with, speed is going to be the key there. And I think the winners in this race will be those who have the best data, the most structured data, and can transmit it faster than anyone else.
RD On REST being slow, I saw a comment that most people who claim to be using REST are basically a sort of RPC, not following the sort of original HTML-first REST protocol. Do you agree with that or do you think REST is a more flexible methodology?
SC I think REST is the more flexible methodology. A little background on me, I was a front end engineer for a long time, and mostly because I was horrible on back end. I know enough to be dangerous and I know enough to make some mistakes, but not enough to really architect a good back end. I love front end engineering, and one of the reasons why I love front end is because JavaScript is so forgiving and I see REST in that same type of light. If we used it exactly as it was meant to be used, yes, it's going to be fast, but regardless of what we want, what we think it should be, once users are using it, that's how they're going to use it. So I think it's absolutely flexible and can do what we need it to do.
RD What is ultimately the difference between the RPC and the REST API?
SC So specifically gRPC, they're meant more server to server and it's a lot less about structured data and it's just about transferring that data as quickly as possible. REST prescribes a certain way that it has to be in JSON, it has to be formatted in certain ways and you're going to be prescriptive on the parameters, the headers and that. I see REST as a server to client and I see RPCs as server to server. So just transferring the data from one database to another is where an RPC is going to really shine, versus server to client where it's client-facing. That's why REST has become synonymous with the web.
RD So the RPC is just robots talking to robots.
SC Yeah, exactly.
RD So do you think with everybody API-ifying their applications, is this going to lead to just one giant client in the end? Everybody just having a massive pile of APIs that it draws from?
SC I hope not, but I think you're not wrong. I think this will be the case for the next 5 to 10 years as this is a whole new world. In the heyday of the internet in the late-90s, early-2000s, when the internet was still kind of the wild, wild west where anything went, we were still trying at that time to create standards. We were trying to understand how to build the internet. And now that we've got 15, 20 years behind us, that's where JavaScript, TypeScript, that's where all these other protocols– GraphQL, gRPC, MQTT, these have all come out because of the needs of what the web has done. As we move into this AI era, especially the agentic era which is where I look and see the next 5 to 10 years going, as we do that, it will be the wild, wild west again. Everyone is going to say, “Hey, I’ve got to get my APIs out there so an AI can do it.” And so on Postman, we have our public API network, for instance. We have over 100,000 APIs on our public API network. Those are publicly available APIs, over 100,000. I would venture to say that within the next five years, really within the next year or two, we're going to see a doubling and tripling of that where everyone is just going to say, “Hey, I need to get my APIs public so that an AI can use it.” And that's where –you said it yourself– we're going to see just a pileup of APIs. Then after that comes out, I think we're going to see new protocols. I've heard rumor probably on Bluesky or LinkedIn, but there's a new agent protocol that a startup is trying to build where it's going to be an agent to agent protocol and I think we'll see those types of APIs come in. And so initially we'll have that big overload of APIs and then it'll settle down. Everyone will have rushed to get their APIs onto the agentic world and then we'll standardize it, we'll clean it up, and it will probably spike and then reduce.
RD And probably the first protocol won’t take if history is a guide, because we're not using SOAP anymore, right?
SC No. For the most part, large enterprises are still using SOAP in their internal stuff.
RD Oh, really?
SC Oh, yeah. But again, it's the legacy heavyweight. It's that 15-year-old payment processing plan, that processing API.
RD COBOL forever.
SC Yeah.
RD So in the agentic future, do you think the agents themselves will be API-accessible?
SC I hope so, I really hope so. I wouldn't be talking about why our APIs are so important in the AI world if I didn't firmly believe that in the agentic era, your agents will have an API and they will have that specific new API protocol that will now make an agent to agent conversation happen. When OpenAI came out and you had ChatGPT-3 and 3.5, the world saw what generic LLMs are going to be able to do. And those are generalist, but in reality what we're seeing, and we built Postbot at Postman, which is our AI assistant, our AI assistant is multi-agenic. We have a main agent that acts as the product manager. They're divvying out the work. A request comes in, a request for something whether it’s generating tests, documentation, visualizing your large data responses, that main agent will then divvy out those tasks to sub-agents, and those sub-agents are ones who are very specific in what they do. So in Postbot for instance, as I said, we have an agent that does only API testing and we have another agent that does only API documentation. What we're finding is that the generalist aspect of AI is really good for public toy use. I use Claude on a regular basis as my go-to for helping me ghostwrite articles, helping me do that, but when I need something very niche, I have to go to a very specific agent. And so as we move into this agentic era, it's going to have to be agent to agent APIs that are talking to themselves, and each one of those agents will have an API. I hope –fingers crossed– that this works, so anyone who is listening and anyone building out this new standard of agentic API protocols, I'd love to beta test it for you.
RD Well, there you go. Put a little help on it. So besides the agentic future, what's the thing you're excited about for the future of APIs?
SC For me, what I'm excited about is an API-first world. We've talked about that for years and we're starting to actually see this come true. You've seen all those end of the world movies where he's like, “The end is near,” and all that and you've got the guy standing on the corner and you think he's crazy. We're over here saying, “Hey, the world is API-first. We need to go move towards an API-first world,” and we felt for a while like we were just yelling into the wind, no one was listening. Agents and AIs come out and now, oh my gosh, your APIs are that much better, they're going to be that much more valuable to you. So what I'm excited about is just building an API-first world where your API is now the first thing you build. When you're looking at building a new feature or teams are building new companies, you look at building your APIs first and then building out everything else because your API is going to be making you money. I think two-thirds of companies are making money off their APIs. For 21%, their APIs are driving 75% of their revenue. That's a crazy statistic in 2024. What's it going to be in ‘25 and 2026 and beyond? We can only venture to guess.
RD That's right. It's going to be robots all the way down.
SC Well, and one of the jokes I talk about is when robots build robots with unclear blueprints, well, let's just say the robot apocalypse probably starts with a poorly documented API.
RD Oh, there you go. Document your APIs.
SC Yes.
[music plays]
RD Well, it is that time of the show again where we shout out somebody who came onto Stack Overflow and dropped a little knowledge, helped out. Today we're shouting out a Lifeboat Badge, awarded to Knossos for answering the question: “What is the difference between TextView and TextViewCompat?” If you are also curious about that, go check out the answer. We'll drop it in the show notes. I am Ryan Donovan. I edit the blog here at Stack Overflow. You can find it at stackoverflow.blog. If you like what you heard today, drop a rating or review, because it helps. And if you want to find me for hot takes, cold tricks, I'm at LinkedIn.
SC And my name is Sterling Chin. I'm a Senior Developer Advocate at Postman. And obviously I'm going to shout out postman.com. This is your main API platform across the world. And you can find me on social media, on LinkedIn, and on Bluesky @SterlingChin.
RD All right. Thank you very much, everybody, and we'll talk to you next time.
[outro music plays]