KMoesif’s Podcast Network: Providing actionable insights for API product managers and other API professionals
We’re very pleased to have Kin Lane, the Chief Evangelist of Postman, joining us today. He has spent the last decade helping organizations think through their API lifecycles and optimize their business processes. He continues to be a prolific writer on his famous blog site, the API Evangelist.
Kin shares his perspectives on API governance, guidelines for deprecating & versioning, and interesting implementations he’s seen with Postman Collections, amongst many others.
Derric Gilling, Moesif’s CEO is your host today.
Make Your API Platform Successful with Moesif!
Transcript
Derric Gilling (Moesif): Welcome to another episode of Moesif’s podcasts. I’m Derric Gilling, your host today and CEO of Moesif, the API analytics platform. Joining me is Kin Lane, otherwise known as the API Evangelist, a veteran of APIs and currently the Chief Evangelist at Postman. Really happy to have you here today, Ken.
Kin Lane (Postman): Thanks for having me. Appreciate it.
Why Postman for The API Evangelist
Kin started The API Evangelist as the face of his consulting business in 2010, helping organizations think through their API lifecycle. By 2019, Postman was one of his top performing tools and thus a natural fit for him, where he now works on problems that are of the scope that he really hankers after.
Derric: Jumping right into it. I’m curious, how did you get into APIs and what led you to Postman?
Kin: So historically I’m a database person and I’m gonna date myself here - 1988 was my first job. So fast forward that, the internet comes out and I’m building database driven web applications. Around 2006 I’m running North American events for SAP, everything from a MeetUp to their 50,000 person flagship Sapphire event. And I started using Amazon APIs in a new way to scale infrastructure. I had never used APIs in that way before. Then around the same time I started getting requests to do more mobile apps and the company that I worked for at the time we were running all of SAP’s North American events and we just took on all of Google’s event. So I when ran Google IO in 2008 and 2009 I was getting asked to build more mobile apps, and then the last one I ran for Google was the year they gave away the first Android phone.
And so in that I saw the role that web APIs were playing and by 2010 I started my own kind of consulting career, which the API evangelist is the face of. And then I spent the last decade just really helping organizations think through their API lifecycle and how to optimize and do things more efficiently. By 2019 Postman was one of the top performing tools in my toolbox, and when I asked what tools people were using Postman was top of mind for everyone.
And so when it comes to really applying what I’ve learned over the last decade and making the rubber meet the road when it comes to the API lifecycle, Postman was really top of that list when it comes to places I could go work. And honestly, I have a daughter going through university now so I needed a job, doing the old hustle didn’t quite pay for college and I kind of like having health insurance now. And I get to work on problems that are of the scope that I really want to, and I get to practice what I’ve been preaching for the last decade. So it’s a good fit.
How Prevalent are APIs
All mainstream companies have now realized they should be doing APIs. APIs are just everywhere, they’re beneath everything that we touch in our personal and business lives.
Derric: Awesome. We’re huge fans of Postman over here at Moesif, and even at our last company - great product and great UI. Interesting to see all of the different roles that have popped up within APIs and Developer Relations - Developer Experience, Product Management, Developer Relations, etcetera. It can become quite ambiguous. What does this all mean - what are these different roles, and how is it organized at Postman?
Kin: When it comes to the API lifecycle I would say more people are getting involved in the conversation. For me, that’s one of the reasons why web APIs, or RESTful APIs were so successful, it’s because they’re simpler and they’re less technical. In their simplest form it’s a URL with a bunch of query parameters that anyone can use, so they’re a lot less complicated to use.
When you have a tool like Postman that allows you to make API calls without writing code, that starts breaking down some of those doorways that exist between classic IT and business. We’ve just started seeing a lot more opening up of people coming into the conversation with a flood of Q&A and testing folks who need to actually test API’s. We’re also starting to see more business stakeholders step up and want the awareness that comes from API management and analytics, requesting dashboards and more insights into what is going on with their API’s - critical pieces behind the web and mobile apps that they’re using to drive business.
We really see that as the API lifecycle expands and grows, APIs aren’t something that we ask “should we be doing them”, it’s something that all mainstream companies have now realized they should be doing. Opening up this layer of awareness to business stakeholders has proven to be pretty critical. We’re seeing sales teams emerge as a persona that we’re catering. According to The State of API Report that Postman produces, I think almost 13,000 people last time filled it out, we’re just seeing a lot more of those roles emerge. And then we’re seeing that inside of Postman as well, we’re seeing more of our marketing folks using Marketo’s APIs or using Salesforce APIs combined with Postman’s Collections to extract the data to make sense of what’s going on.
And so APIs are just everywhere, they’re beneath everything that we touch in our personal and business lives. And I think more people are waking up to that fact and they’re needing tools that help them make sense out of this world that’s kind of unfolded under our feet. But is also fast growing and fast changing and evolving.
Standardizing APIs Across Your Company
Postman’s Collections makes everyone row in the same direction. By setting up an API call, saving it as a Collection, and then sharing it amongst other stakeholders, you really start standardizing how people talk and communicate and work around things.
Derric: Definitely, and when it comes to things like Postman Collections what are some of the more interesting things that you’ve seen or more interesting surprises when different companies try and implement new APIs.
Kin: Once you have a Collection with a set of tests running on it you’re able to start measuring all APIs across an organization equally in a standardized way. So, people start to think about not just testing, but also governance and it reveals how different APIs are across the same organization. The company might be Adobe or Microsoft, but how they build APIs across each team varies widely, and I don’t think people always see that. Once you start standardizing, saving Collections, running tests, sharing them and collaborating across teams, you start seeing some of the weird things that can emerge. I think people are really realizing that we’re not all rowing in the exact same direction that as we thought we were.
And so when you’re able to set up an API call, save it as a Collection and then share it amongst other stakeholders and say “just hit run on this and see what you get,” you start really kind of standardizing how people talk and communicate and work around things. I would say people just don’t always realize how different each team approaches APIs and those differences across orgs are pretty eye opening for a lot of folks.
How to do Governance
To get people to adhere to compliance, you have to invest in training, education and feedback loops around governance, otherwise you end up people not really caring
Derric: Do you see a difference when it comes to API governance at a larger company versus maybe a smaller startup.
Kin: Well, I would say it’s a lot more of the human aspect to kind of set in motion. When you’re at a smaller company and you want to do governance, you’ve got less of a surface area, less people involved in that, so it’s sometimes a little easier to institute. But, as the number of teams, number of APIs grows, that becomes a much more human thing — you have to go around and educate people about what is Postman, what is OpenAPI, how do you use OpenAPI to define your contracts. Oh, and then here’s how you use Postman to test and monitor and execute those API calls in a way that we can report on governance.
I would say that the biggest difference is really just that investing in the human training, education, workshops, feedback loop around governance. Otherwise, you end up with people not really caring, people revolting, saying “well hey, we don’t want to do that,” because we haven’t given any feedback on what is governance, why governance and what those tests are about and what the reporting is. And so, just the larger the group the more kind of dog and pony show you got to have around why governance, what it is, and then that evolution of it. Because if you don’t have the team’s buy in it’s going to be pretty hard to do. And that’s just a lot easier when your company’s smaller.
DevEx is More Than Documentation
Documentation and a portal are table stakes. Analytics, usage and insight into what’s going on with your own API consumption is next, but you should aim for is to make it a shared experience by providing insights into what others in the dev community are doing.
Derric: Definitely. Moving on to the next area which is around developer experience. You hear a lot about around developer empathy, but what does it mean to be developer first?
Kin: Oh, yeah. I think developer experience definitely starts with a portal and documentation around your API, but providing them with analytics, usage and insight into what’s going on with their API consumption. Early API management was really about developing awareness for the provider, putting a rate limit in front of it, measuring it and then providing analytics so you understand how your APIs are being used. The ones that kind of internalize that and really care about their developers, also share that with their developers — that awareness that insight, their little slice of the pie. So giving developers a piece of that dashboard and analytics and insights, so that they can improve their usage and understand what they’re using, or what they’re not or if their app is super chatty. And then sharing what are other developers doing, what are people doing in similar industries? How does my usage size up against other developers? And so it becomes a shared developer experience.
So it’s just not “hey your docs are great,” and I’m getting the awareness as a developer through a dashboard that you provide me, but I also feel like I’m part of a community. I see how other people are doing it. I can improve my apps and my consumption. I can make them less chatty, because I’m pulling the hell out of the API. But, oh, look over here, there’s a group of developers using web hooks. I don’t even know about web hooks. And so I would say that that community sharing of the insights and awareness that APIs bring, that API Management has brought, and making sure that they’re tuned in, that it’s providing value to their world.
Then I would say you have some actionable goals around activating them. So how do you actually activate and increase the engagement of your developers through a better and perpetually improving developer experience — by providing them with more insights and understanding.
Measuring Developer Activation and Success
Before we can measure activation we need to define what is a platform versus an API, and a platform versus an app being built on it. What we measure and report on, and how we then activate and move developers forward, varies widely depending upon if you’re building a mobile app, web app, widget, an IoT app or doing an iPaaS-like integration.
Derric: Cool. And when it comes to that that activation, are there ways to measure developer activation and what does developer success look like?
Kin: Yeah, I mean that’s really tough because I’ve kind of been pushing on this notion. When I sign up as a developer for the Twitter API for example, I have to sign up and say, oh, here’s my app that I’m building, give you a title and description, before Twitter will give me my keys. And most of the time I don’t know what I’m building. Especially me as the API Evangelist, I’m usually not building an app, I’m usually just kicking the tires, writing a story, understanding what’s possible. So the paradigm of an app never fit me. But I’m also, I would say, a special snowflake, and in that context, I’m trying many different APIs and never building an app. But even for those who are building an app, or the notion of what is an app, I’m just building an integration, I just want that Twitter data in a Google Sheet. I just want to be able to integrate the SaaS services that I depend on each day to help make sense of this.
So I think the notion of what is an app needs to evolve, before we can deliver the proper developer experience, and before we can start really measuring that effectively. If someone’s just doing a iPaaS-like integration, the metrics are going to be radically different than if I’m building a mobile app or if I’m building a web app, or if I’m building a widget or if I’m building an IoT app. And so the types of metrics, what we measure and report upon, and how we then activate and move developers forward, that experience is going to vary very widely. It gets back to, I would say, those personas of who’s actually using our API. Is it hardcore backend developers building mobile apps or is it business people looking to better orchestrate and connect the systems they use on a regular basis? So I think people have got to start really getting a handle on what is an app, or does this even apply, should we throw the concept of app out the door. Should we just let users sign up and just start playing with things. I think that’s one of the frustrations I have with a lot APIs.
If I’m on Twitter I have to go to developer.twitter.com to a separate area and, sure I can authenticate and sign up with my Twitter account, but I still have to create apps and get my metrics over there. It’s always this other place. Where if you use solutions like Cloudflare, they do this really well, where me as a user of Cloudflare logs in and behind every dashboard widget on the page, not everyone, but most of them, there’s an API button in the bottom corner that I can grab the API call, with the key. To make a call to that API I just grab it, copy and paste into Postman, or other, and hit send. My Account isn’t separate; My keys aren’t separate. So I think the notion of what is Developer Experience needs to be melded with just what is that app experience, or what is that platform experience, what is the holistic overall platform experience that we need to cater to, to get people using APIs. I think once we get over that kind of friction point in the current notion of what is a platform versus an API, platform versus an app being built on that, I think you’re going to see entirely new types of usage emerging, new ways of measuring and creating experiences for folks.
Derric: This is a really interesting point where, in this case, it’s not about having a single developer experience, but it’s actually more of a way of thinking. It’s embedded within the app, it doesn’t matter what team you’re part of.
Kin: Yeah, and that kind of thinking is going to be more aligned with your business goals. Too many, too often, and API is a secondary project that got done and we check that box. It’s not in alignment with the overall core business goals, because it was this side thing done over here and you link to it over here. No, it should be part of what is our platform experience and integrations, and SaaS integrations like Zapier and this and that are commonplace. Low code/No code automation with APIs is common place and that does not fit into this sidebar narrative of what is Developer Experience. It should just be your overall platform user experience.
How to Evaluate DevRel
Developer Relations should be measured on translating your APIs and developer cycles into something that solves a real-world business problem and, in the process, brings customers to us
Derric: Then if I’m part of a developer experience team, what should be I be judged on? Is it revenue, or is it something different?
Kin: Hard to say. For revenue you’re going to just piss a bunch of people off pretty quickly. Depending on your developer team, you’re gonna rub them the wrong pretty quickly. Maybe that’s one of the things that causes the misalignment with the overall business objectives, is, we as developers, we’re these special snowflakes off over here and don’t make us sell.
But we also need our paychecks to be paid and the company’s got to make money or we all lose our jobs. So I think we need to just start having a more honest conversation about that. But, I think ultimately for me, I want them as DevRel or evangelism, or any spectrum in between, I want to be measured on the impact that I’m making. So that’s going to be stories I tell, blog posts, webinars, white papers, case studies, things like that. So I should be measured on the stories and the impact of those stories that I make measuring high reach.
In Postman one of my OKRs that I have to report on is the number of Collections that I get added to the Postman network. Now, this may seem very Postman specific, but it’s not because Postman Collections for me is a gauge of the business values and why we’re actually doing this. The first one’s always “here’s the entire API reference Collection,” here’s all the things that are possible. That’s pretty ground zero — and that’s pretty boring. The next Collection is always a more DevOps/APIOps, business workflow Collection. Alright, so if it’s an e-commerce API, here’s the first reference Collection - all the endpoints. But, the next one is searching for a product, adding it to a cart, checking out the cart, getting that invoice. Okay, I want that Collection that does all of those steps and as a self-contained Collection. And so it’s really those second-generation and third-generation Collections that start getting at what the business value is, why we’re actually doing this.
And so, those are the types of things that I think DevRel should be measured against. How do I translate our APIs and developer cycles into something that solves an actual real-world problem, a real business use case, and then brings customers to us. So that “brings customers to us” can kind of be decoupled from us, to make us feel warm and fuzzy as DevRel people in our little bubble. But I think that that action right up to that still has to be there, and we’ve got to be held accountable for it.
APIOps Definition
APIOps is the combination of API-related tasks to create a version of your enterprise capability, something that’s actually tangible from your daily work
Derric: And this brings up a really good point around APIOps, trying to align it back to business value. But what do all these different buzzwords mean, APIOps, API Observability, and there’s a few others floating around.
Kin: APIOps for me is just an extension of DevOps, which are the little incremental things that we have to do throughout our day to get our job done. It’s setting up a database, it’s indexing that database, it’s pushing code, CI/CD, it’s running a test as part of that CI/CD. So breaking down all those tasks and looking at them and saying as a developer this is what I need to accomplish in a day.
As the roles you talked about earlier expand, what does DevOps look like for them? If I’m a QA tester, or an analyst, or working in sales, or marketing automation enablement, what are those little tasks that I need to accomplish during my day. If you’re in marketing, Salesforce’s Marketo is one of those platforms that I depend on. But what are those little functional things I need to accomplish? Back to what I said about a reference Collection, the reference Collection for Marketo is here’s the entire menu of everything you can do with the Marketo platform. APIOps or DevOps is how do we then combine one or many of those API calls into something that is actually tangible in my daily work.
As a developer, all the way up to these other business personas the key part for me is really defining what those are because that becomes a version of your enterprise capability — that’s what you’re capable of accomplishing on a daily basis. Having them defined as Collections, having them executable and usable and shareable, I can say “hey look, I set up this cool new workflow with sales between Salesforce and whatever.” I can capture that, I can then share it with a team member and say “hey, do this.” And then they can tweak and make it work for their world and it’s that type of ops-level collaboration. I think that is where the rubber is really going to meet the road in the next decade.
Versioning Guidelines
There are lots of opinions on versioning, from not doing it at all like at Netflix, to OpenAPI where you need to semantically version your code, Collections and documentation. Either way, versioning comes down to just having a strategy, realizing the communication and making sure that, depending on your audience, you’re communicating the change management plan in the right way.
Derric: Really love looking at it from a collaboration standpoint, how to get more people using these different APIs and the various Collections. But at some point, we’ve got to get rid of them — there’s a lifecycle for all of these products. What are some good things you’ve seen in terms of deprecation guidelines and versioning guidelines, and where do people usually mess up?
Kin: Versioning is tough, as far as API lifecycle. There’s a lot of opinions on how you do it, even a lot of opinions on not doing it, that you shouldn’t do it at all — versioning is bad. For me versioning is just really being open and honest about change. It’s about change management and having a plan. If your plan is to not actually semantically version your code or your Collections of your APIs, or your documentation, great, but have a plan and communicate that and show how it actually allows you to move faster and produces less friction. If you just kind of throw it out there and say we don’t version because we don’t want to, and then you have no change management plan, that’s not the way you want to go. I’ve seen both ways. I know that Netflix is one that they do very well without versioning, they have a whole different strategy. You can tune into their engineering blog if you want to learn more about that.
Semantic versioning is kind of dominant, really having a strategy, defining what is change and then how to communicate that internally amongst teams and then externally with our consumers. That’s really the core of what is versioning is to me. It’s not the technical details of doing it, it’s that we have a plan and we’re communicating around it and people understand what we’re saying when we talk about it.
OpenAPI is with semantic versioning is one of the ways that you stabilize this communication. Here’s a contract for version one, this is what I mean, this is what you’re going to get. When we go to version 1.2, here’s what you’re going to get, here’s what I mean, and here’s the timeframe of when you’re going to get it. Then you’re communicating expectations around change: “Okay, we’re at version 12 and version 9’s going to go away because we only support X amount of versions.” So really it’s not semantic versioning that is the real meaningful thing there, it’s the fact that I can communicate to you what is version 9, what is 10, 11, 12, 13. I can communicate effectively a time frame of when version 9 is going to be deprecated.
How do I communicate that with you? A lot of Rastafarians and people who believe in using the web, believe that the version should be in the header of your API, it should never be in the path of your API. Now, if you’re actually working in the space you realize no, actually about 70% of the versions you come across are in the path, which like goes against everything the Rastafarians believed in and the Scripture that was handed down from the API gods. But the problem is that a lot of developers don’t know headers exists, and so they don’t even know to look for the version in the headers. And thus the communication around change breaks down. When it’s in the path it’s right in your face and it’s easy to understand and it’s easy to navigate between major versions. That just shows the importance of communication, and that’s the thing around change management that matters. We’re able to say, “Hey, you’re on this version; Hey, I’m on this version; Hey, you need to switch to this version.” If you look at Stripe, when you come in and at the first API call you make, they pin you to a version. And that’s the version you’re at. That’s the mindset people are in when they onboard — you’re using this version, that’s your Stripe context. Don’t mess with that. I’m working in that context until I say I want to go to another version. So really versioning comes down to just having a strategy, realizing the communication and making sure that, depending on your audience, you’re communicating those things in the right way.
There’s other things you can do like there’s a sunset header that you can pass: when are we going to deprecate this and then as that time frame moves closer that header can be used to communicate this in different ways. The biggest damage and problems that I see people make with versioning is that they don’t communicate, they don’t have a plan. If you’re launching an API you should have a deprecation date: I plan on supporting this version that we just created for 18 months. And most APIs don’t do that, so it could live forever. But then what usually happens is because we never communicated that this API could just disappear next week, because I never really communicated when it’s going to go away, or how long it’s going to be around, so therefore I reserve the right to just make it disappear next week. And it’s that kind of breakdown in communication that are the biggest sins I think that we see across the space.
HTTP Headers are Very Important
The smartest PhD engineers often don’t know about HTTP headers. Everyone should take a course in HTTP and learn about headers, query parameters and body parameters.
Derric: Totally agree that communicating anything with deprecation or change of versions is really important, especially as you mentioned, adding it to the URL. Now with stuff like web hooks it’s right in your face. Sometimes those headers can get buried and you don’t see the header.
Kin: I’m always amazed that the super smart PhD-level programmers like that I come across in my career, who don’t know about headers. I would never call someone stupid or dumb for not knowing that, because it’s just that there’s so many things blasting around us that I don’t think everyone got the HTTP course. They were doing C++, and they were doing the hardcore things, and they just never quite learned about the web and how HTTP works. When I finally got that I was like “oh, wow, okay, so now I’m in the know.” But a lot of people out there who are super smart, super competent and capable, but just don’t quite get an HTTP header, what it is and how much gets stuffed in that. What’s the difference between it and a query parameter or body parameter. I don’t think there’s a lot of awareness around that and there should be a little bit more training and workshops for people.
KYC So You Can Communicate Change
You need to have a nice logical pace strolling forward and reaching back as part of change management communication. If you know who your customers are, and you regularly talk to them, then you can march forward pretty fast.
Derric: And how forceful should an API product manager be at pushing someone to the next version or to a new API? And what are some other ways to communicate if those deprecation headers get buried?
Kin: This is where it goes beyond the technology of APIs and into the business. I had one time a print API that I was designing the new version for. We only had five users left on the oldest version, so let’s push them all off. Four of them went. The fifth one submitted a print job every Monday morning that was worth $500,000. We didn’t force them to version and switch. The guy who built it left and they didn’t know how to switch it. The whole company’s print for the week was dependent on this and it was $500,000. So guess what? We stopped pushing it on them. You know, there’s things like that that are just out of technical control. But I would say you want to have a nice logical pace strolling forward and reaching back as part of change management communication. “Hey, are we leaving anybody behind. Hey, you guys in the back there. What do you need to understand the future and move forward?”
And don’t support too wide of a spread of APIs. Look at Salesforce, they’re still supporting that first API that they stood up. And they won. That’s 20 years later. I mean, do you want to be doing that? So again, it comes down to the communication. You just have to be knowing who your consumer is. Really it comes down to the API management layer and the analytics and awareness. If you don’t know who your consumers are and you’ve never had a conversation with them, then you probably can’t push them forward too fast. But if you know who they are and you regularly have conversations with them, you can probably march forward pretty fast.
Forcing Upgrades for Security Vulnerabilities
By aiming to provide a robust and complete platform development kit/SDK, you ensure your code is less brittle and your customers don’t have to do take care of integration issues. By providing more of resources to your consumers, you have a greater say on how they move forward.
Derric: Definitely agree there. Before making any big decision like that you need to understand who was impacted and what the impact is to both your customers and your business. Sometimes we have to force people to a new version if there’s a security vulnerability or something like that. When is it up to the provider to say “hey, I’m responsible for my customers’ integrations” and actually get them to the next version? And how can you actually force that to happen?
Kin: You’ve got to make calls on how you allow for integrations. This was supposedly one of the promises of hypermedia where, when you issue new versions, you’re not going to break all your clients because they’re version agnostic. They have a set of links that they follow and they know to look for that next and previous link in an API call. I’m not actually bound to the next one always being /V3/ for example. It really comes down to how you design your APIs and then that’s how you enable your consumers to design and develop their integrations.
If you’re providing them with SDKs that are robust and well done, and they don’t have to write a lot of that code, you’re going to have less brittle code, and you’re going to have more control over the code that’s in people’s applications. This is really more than that SDK, it’s a Platform Development Kit. If you’re providing more of those resources to your consumers you’re going to have a greater say on how they can move forward, because you’ve taken on ownership of those integration details. You’re then able to say “hey, this isn’t going to break something, we’re going to go forward to version eight, you’re all going to come along, oh wait, except for you, because you did your own little custom thing.” But hopefully you can minimize those pools by providing more integration resources for people.
Tired of Supporting Multiple Client Libraries
With OpenAPI’s code gen piece you can automatically generate, refine and clean up your client libraries in a variety of languages much faster, much quicker and in a much more consistent way. Your docs and overall DevEx will be much better.
Derric: Has OpenAPI changed any of this, especially when it comes to SDK design and communicating changes?
Kin: Yeah, it’s really, I would say it’s kind of the crux of why I see a lot of major providers switching to OpenAPI recently — it’s because of the the code gen capabilities. They’re tired of supporting 10 different programming language SDKs that are all hand rolled. They’ve realized that if they just invest in their OpenAPI properly, auto generate, auto refine and clean that up, then that becomes the central truth of the API lifecycle. Then your docs and your overall developer experience are better. But yeah, it really pushes on that code gen piece. You can generate your client libraries in a variety of languages much faster, much quicker, in a much more consistent way. And then you can also get at some of those other integrations as well so other iPaaS platforms, like the Zapiers, can just grab your OpenAPI for your platform and boom, you’ve got an integration and you’re on an integrations page for iPaaS. Same with other SaaS providers, if they want to add you to their integration page they don’t have to wait for you to do it, they can just grab your OpenAPI and do that. That just adds to the playing field when it comes to the integrations that are possible and they’re all dependent on that contract, that OpenAPI truth. They’re not all custom code, custom developments that are going to break when you do march forward.
Stabilizing Your API Lifecycle
In the near future APIs will need to be OpenAPI and contract driven. Through a complete and robust OpenAPI definition you’ll do docs, mocks, test generation, security scanning, code gen, discoverability and compliance.
Derric: No, definitely. And when it comes to stuff like OpenAPI super exciting to see the change and different tools in the API space. But what’s next for API’s, a lot of stuff has changed in the last half a year?
Kin: For me it’s a lot more of the same. I’m seeing Salesforce, Twilio, Dropbox and Twitter all adopt an OpenAPI-driven API lifecycle for the reasons we just talked about. And so I would say it’s more of that, it’s like people realizing that we’re not just doing Swagger because we need docs, we’ve actually realized swagger is not the spec anymore. We’re doing OpenAPI and we’re doing docs, we’re doing mocks, we’re doing test generation, we’re doing security scanning and fuzzing and we’re doing code gen. We’re really going all in on API first, meaning that we’ve got to have a contract before we develop anything on top of it. This contract is driving every stop along our API lifecycle, which is now well defined. That’s the next decade. I’ve been doing this for 10 years and I realize that none of this moves forward as fast as we would like. So that’s really the the big piece.
I would say the new elements of that are going to be around discoverability, meaning that now you can find all your APIs because you have a contract defined for them. Now you can actually be compliant and now you can actually scan all of your APIs consistently. API providers will require that before an API goes into production there’s got to be a complete and robust OpenAPI definition before you can ever push anything to a pipeline. So I would say that’s really the future, and I know people hate it when I do these because it’s not super cool, but just stabilizing your lifecycle, making it OpenAPI and contract driven.
But with that said, I would say what comes with that maturity is people then realizing that we need to do webhooks because we’ve got a couple of successful APIs that people are pulling a lot. So to reduce that infrastructure load we’re going to publish some webhooks. And oh, by the way, we should also probably do a Pub/Sub, NATS or Kafka, or some other TCP related thing. Expanding your API toolbox beyond just REST and going GraphQL, and going Pub/Sub, and using web sockets or going gRPC. I would say that what’s next is really acknowledging that it’s a diverse API toolbox, it’s not just REST. That will remain King, top, it’ll be the kind of gateway drug for anyone doing API’s, it’ll be the base of our API operation, but depending on your consumers and the types of applications and integrations you’re doing, you might need a GraphQL API that’s more data intensive and giving your developers a little bit more control over querying. If you’re heavy B2B you’re probably going to go with some gRPC APIs that are a little more higher performing. But, we still need all of the same basic stuff that came with API management. We still need analytics, rate limiting and insights into all of those layers. We still need testing, mocking, documentation. So we need the same stops along the API lifecycle, it’s just the future’s really not going to be just HTTP/1.1, it’s likely going to be HTTP/3, it’s likely going to be TCP, it’s going to be MQTT if it’s more than deviced IoT, and that diverse toolbox really represents the future.
Is There a Market for GraphQL
GraphQL is not a replacement for REST. If your consumers are rapidly building certain types of mobile-responsive applications and they really understand your underlying data model, then GraphQL provides a more flexible and agile way of getting data and content out there.
Derric: We’re really happy that you touched on GraphQL. Super exciting area right now in the enterprise. What some of the challenges when it comes to GraphQL? Is it something that everyone should adopt? Sounds like sometimes this is like the SQL versus no SQL debate. Or does it make sense for every application?
Kin: So whether it’s something everyone should adopt - no. Whether it’s a critical tool and in some people’s toolbox - yes. The biggest challenge of GraphQL is the way that it was positioned and sold. It was positioned as a replacement for REST. It’s not. It’s not a replacement for REST. It’s not an API pattern that works for all APIs. Now, if you’ve got a known set of consumers who are rapidly building certain types of mobile-responsive applications, who really understand your underlying data model, hell, yes. Give them a GraphQL endpoint and get the hell out of their way. Let them do what they do best. So if it’s a data project with those types of setup, yeah. If you’ve got known users, it is a must have. But, look at what Github is doing now, they’ve made a real big push into OpenAPI recently. I think they’re going to still do some storytelling about why they’re doubling down on OpenAPI and REST API, while also still supporting GraphQL. I think there’s a lot of lessons to be learned in there that we’ll hear about.
It should be part of your diverse API toolbox. I would say some of the other challenges with GraphQL are that I wish the creators had embraced HTTP standards a little bit more. I agree that we need a query pattern that’s standardized, should be baked. HTTP shouldn’t be a separate thing, because then you’re going to start solving other challenges with GraphQL around caching and performance. A lot of those solutions have been done in a proprietary way, like use this vendor’s tool and then caching’s just magically done for you. That should be an HTTP standard as well — there’s a lot of caching solutions in there. So really, those are some of the challenges. But in the right situation, if you know who your consumers are, GraphQL is going to allow you to build things a lot faster, be a lot more flexible and agile on how to get data and content out there. So there’s definitely a place for that.
Derric: Totally agree it’s hard when it comes to the stuff like caching where we already did have standards around that and now GraphQL breaks everything. Even status codes, I’m not sure why we can’t just use the same HTTP status codes that we already have.
Kin: Yeah. But this is what happens when you don’t really embrace the web or understand it. It’s akin to what we talked about earlier with the header literacy. A lot of people just take for granted the web and how much work, how much investment and how much it actually brings to the table. Before they go building these new solutions they should spend some more time understanding the web and go, “oh, that’s why status codes exist.” It’s back to what I said about change management, status codes are about communication, they’re about communicating good things and bad things, and whose fault it is and at scale. And we’ve already hashed these out and let’s not reinvent the wheel.
Are There Any Good Resources for APIs
The best canonical spaces where you can get up to speed on APIs include The API Evangelist, Nordic APIs, newsletters from Matt Reinbold and James Higginbotham, and the Postman API Network
Derric: Totally agree. When it comes to education and getting into API’s, what are some recommendations for new college grads out there looking to start a career in APIs or Developer Relations?
Kin: Well, I’m biased, but of course you should start at APIEvangelist.com. Beyond that, Nordic APIs is a great place to get information about the API space. I have a round up called API Knowledge Center. I actually should put it as a banner on the homepage of API Evangelist. I think I’ll do that this week. It’s a roundup of what are the resources in the space, a listing of all the top API blogs. There’s a handful of API newsletters out there. My friend Matt Reinbold’s got one. James Higginbotham has another. So search for the handful of API newsletters, both of those come up if you Google it. Those will keep you in tune with what’s going on, give you a good roundup of stories. But really, we’re working hard to kind of invest in the Postman platform for onboarding new developers. So the Postman API network, there’s quite a few APIs in there. I have one that’s a public REST API, that it’s like 100 different APIs that don’t require authentication, so they’re really easy to use. There’s ones for every topic: if you’re into books, if you’re into cats, if you’re into dogs. I got one on Bitcoin, there’s one on Chuck Norris jokes. So whatever you’re interested in, there’s a free public API public you can then kick the tires on and see what it’s all about. It’s easy to use with Postman. I’m trying to create more of those Collections to onboard folks.
I do a lot of speaking to university students to try to convince them why APIs matter, why it’s going to impact their career. And so I’m building more of these types of Collections that show “hey, you’re going into archaeology, here’s a Collection for you.” “Hey, you’re going into accounting, here’s a Collection for you.” Going into public policy management, here’s one for you.” So I’ve been working on more of those, but there’s a handful in the Postman network that will kind of onboard you with the world of APIs, help you kind of see it. But, with that said, this is something that us, in the space collectively, should got better at - creating more of a canonical space where you can get up to speed on APIs. It’s historically been ProgrammableWeb, but it’s just not the destination and source it should be, or it needs to be, to get us into the future. I would say it still represents the last 15 years, not really the next 15 years. So we need to do better.
Derric: I’m going to definitely have to take a look at the Chuck Norris jokes. That looks quite interesting. Well, thank you very much for joining us today. We always love hearing your insights on the API space and API lifecycle. Have a good one.
Kin: Yeah, you guys know where to find me. Let me know if you need to do more.
