Be API-First, Not API-Last, Kin Lane, Postman | Postman Galaxy 2021

And then, now, I appreciate Kin Lane, obviously you need no introduction, our amazing moderator and chief evangelist. Appreciate you showing us a little bit about your talk, “Be API First, Not API Last.” So with that I’ll turn it over. Thank you so much for yours.

All right, I appreciate it. Well, welcome everybody. Happy to, coming down off of the Woz talk a little bit, so I’m going to try to channel it and be balanced and measured for this talk. So I’m keeping an eye on the Slido. I will just kind of continue through my talk. I urge you to ask your questions maybe towards the end, but feel free to ask as it’s ongoing, and I’ll either answer or I’ll wait till the end to queue them up.

So all right, well, let’s talk about how you be API first, not API last. Let me introduce myself, if I can get my slide to work. There it goes. My name is Kin Lane, I’m chief evangelist here at Postman. Some of you might know me as API Evangelist. I’ve been studying the API lifecycle for the last decade, and in the last year I just joined Postman to continue the work as part of the Postman team, just kind of telling stories as part of our events, on our blog, and just generally in our community, but also working with our customers directly when it comes to listening to their stories about what they’re facing and then translating that into what it is that I do as chief evangelist, helping people understand what’s possible with APIs.

So this is the phrase that I use a lot, I’ve heard used a lot. It’s been around for a number of years. I would say four or five, maybe about six, seven years ago I started hearing it, and I think it’s a phrase that means a lot of different things to a lot of different folks. And what I’m going to try to do today is I’d like to elevate you just above that conversation and show you the wider impact of API first, and hopefully elevate what it means to you.

I think if you talk to developers, you’re going to get two answers for what is API first. First and foremost, you’re going to get developers who say, well, it’s just about developing an API before we develop mobile applications. And that’s true, that’s definitely API first, you’re thinking about APIs before you’re building any specific endpoint or project, which is oftentimes the more tangible piece of what we’re trying to do. The second answer you’re going to get, among your more progressive developers, is you’re going to get an API design first response, meaning that we design the API before we ever write any code, and we plan that API using OpenAPI, AsyncAPI, JSON Schema and Postman collections. We use that to kind of inform the conversation around what is this API, what’s it going to do, what business stakeholders is it going to engage with. And so those are mostly the two answers you’re going to get from folks, and they’re both accurate, they’re both right on the money, and they both encompass a lot of ideas of what’s being API first. So if you’re not doing API design first, you’re doing API code first, don’t listen that, hey, you’re doing it wrong, you’re not, it’s a subset of what you should be thinking about and doing, and it’s healthy and normal. If you’re doing API design first and you’re thinking about your APIs ahead of time, that’s great. Let me kind of show you the bigger picture and why it matters and how you might want to be shifting your views a little bit.

Hi Kim, welcome. I switched back to the chat, so let me look at the questions real quick before I move on. No questions, I’m going to keep it on the chat and that helps me know that you guys are there and makes it feel more like there’s an audience other than screaming into the void.

Hold up, I’ll monitor the Slido for you, Kin.

Okay, that’d be great. I’ll poke over there once in a while, but the chat feels a little bit more human.

So before we talk about what is API first, let’s recap what is an API, because I’m guessing you’re seeing it still from a pretty low level even though APIs are pretty high level. I think it helps to kind of step back and think about it. So applications, don’t think of this just in terms of a mobile application or a web application, think of it in terms of applying something, anything that you’re going to apply, any sort of application that you’re going to need to take care of as part of your daily work. This is, I’m talking about a programming interface for this. So your entire job, what you do on a daily basis, everything you interact with, having a programming interface for that. So all the resources you need to do your job, the contacts that you need, the content for the website, the tweets, the videos, the podcasts, the audio files, all of these resources that you are dependent on across your job, this is what APIs are about. It’s a programming interface so that you can apply those resources.

And it’s also your capabilities. So it’s your organizational capabilities, it’s being able to watch a video, play a video, send it, share a video, it’s being able to tweet, post a tweet, post a Facebook post, post on Instagram, these are all of your organizational capabilities, it’s adding a CRM record, these are what you should be able to accomplish and the digital resources you’re going to need access to on a daily basis to be successful at work. And then if you’re in the API building aspect of this, I’m just, for resources and capabilities this is very much a consumer putting resources and utilizing capabilities, but if you’re building APIs you’re building products and services, digital services that you want to make available to folks, this is what you’re building. So APIs, this is just an interface across your entire organization and what you should be doing to accomplish your business objectives each day.

So let’s look at who is API first. So pretty much every leading brand in technology. So if you look out across the playing field, now all these companies aren’t API design first, some of them are still code first, some of them are design first, some of them are more internal API, some of them are more public facing, but they all have realized the importance of APIs early on, they’re leading with it. So you think about what eBay and Amazon have done to commerce, think about what Facebook and Twitter have done to social, think about what Amazon’s done with the cloud, and then once we ended up with the mobile phones in our pocket, think about the impact of Stripe, Twilio, Instagram, Expedia, all of these brands have changed kind of how we do business on a daily basis, and it’s APIs there, it’s them being API first, seeing the potential of this and putting it forward in their operations.

So from my vantage point, what is API first? It’s seeing APIs, seeing APIs everywhere beneath the surface of everything that we do on a daily basis. All of the applications that we use, all of those apps on our phone, everything is APIs, whether it’s an internal application, it’s an external partner, that you see APIs. And more importantly, you’re prioritizing APIs in your planning around this. You’re planning around their usage, their construction, their evolution. So you’re seeing them, you’re prioritizing, planning ahead to make things happen. And then you’re defining and designing, you’re taking the time to carefully define what it is you need and providing a design that matters, that’ll actually solve the problem. And then you’re sharing that with folks, you’re actually making sure that the stakeholders are at the table, people are involved, and you’re all working with common standards. And then you’re iterating on those designs and those definitions. So it’s not just a very technical thing, this is, as a human, this is organizational, this is something that business and IT folks are involved in. And so you’re thinking APIs early on, before you’re ever implementing any application, in the early phases of any application design process you’re thinking API first. What can we do to be utilizing existing APIs across our infrastructure? What can we be doing to define newer ones? And then use third-party, partner, other types of APIs that are already available on the market.

So how do you do API first? Well, like I said, you do it before you actually implement any of these types of applications. If you’re building desktop applications, web or mobile, you’re thinking about what an API should look like, should be like, what APIs already exist out there is an important piece of it. So before you’re embarking on any of these more tangible, business-facing projects, you’re doing API first, you’re thinking about it, you’re planning, you’re designing and defining what it is you need for the APIs to drive this. And then this is going to open up and transform, that you’re able to then work with multiple devices, types of devices, and be able to understand the API exists there. But more importantly, you’re going to be able to control and define the network, so your DNS all the way down to the VPN, and then you’re going to realize that your infrastructure actually has APIs. So the infrastructure used to drive your APIs have APIs, allowing you to further automate and streamline how you’re actually delivering applications, desktop, web, mobile device, or defining the network around your applications using the infrastructure that you depend on. And then all of this opens you up for more seamless, more fluid partner relationships. Your resources, your capabilities are already available, it’s something you’re thinking about first, it’s not something you have to scramble to make available to your partners, it just is.

And then to further show that API first isn’t just a technical thing, it’s why SaaS is working. You shouldn’t be buying a software as a service if it doesn’t have an API. You shouldn’t be buying any application that doesn’t have an API. You should be thinking API first before you invest in that, because you don’t want to be locked in, you don’t want to just have to be using their system and not have it seamlessly work with your own other systems, let alone your partner ones. And so you do API first by realizing what the impact is across all of these channels, and it’s going to change how you see the landscape across your organization.

So how do you sustain this? I’m going to admit, API first isn’t easy. It’s not something you can just say, oh, we’re going to do, and it happens. You have to have a plan and a strategy for how you’re going to actually implement and start rolling this out, and it’s something that’s very contract driven. So API contracts being OpenAPI, AsyncAPI and JSON Schema for the modeling, and then how do you derive and generate Postman collections from those contracts to just describe different business situations, different business use cases that you need to test for, providing documentation to public consumers or private partner consumers, being able to define and share and work around those contracts. And those contracts reflect standard business and industry standards. So we’re talking PSD2 if you’re in banking, FHIR if you’re in healthcare, there’s plenty of existing standards, Schema.org when it comes to data modeling, there’s a wealth of industry standards out there that you should be using and considering as you’re developing these contracts. And then all of the artifacts, all of these contracts, have to be discoverable, and you’ve got to be able to search across them with no extra work. It’s got to all be discoverable. So your API operations, your API factory floor, should have APIs as part of the infrastructure, but the APIs that are putting it all to use should be discoverable and searchable.

So quick question, Thiago. How would you have a list of API standards for industry to share? I know in telco they use TM Forum Open APIs. So yeah, we’re pulling together right now what we call an API specification toolbox. You can, I didn’t plug the URL in here, but I’ll tweet it out afterwards. We’re pulling together what are all the core standards for defining contracts, OpenAPI, AsyncAPI, JSON Schema, Postman collections, but also what are the industry ones per business sector. So API specification toolbox, you can learn more about that.

But then all of these contracts are test driven, meaning as you’re designing and defining these contracts using industry standards, you’re crafting tests before you ever start programming, you ever start coding, you have your tests defined as individual modular collections that can then be executed to verify those contracts as they progress through the design process and as they move into production. And all of this again has to be searchable and discoverable. And then you’re communicating around this. There’s a feedback loop around all of this. People are trained in OpenAPI, people are trained in these standards, and people are trained how to do testing, they’re educated about how all this works, and they’re shown how they can share, collaborate, find the workspaces with the contracts that they need. How do they discover this? How do they participate throughout the process? And everyone’s got to be trained on this, not just developers or API developers, business consumers also need to be part of this process. And all of this is essential to sustaining this all in the long term.

So why are we doing this? Multi-channel, showed you desktop, web, mobile device, network, infrastructure. You’re able to utilize and publish and consume APIs across multiple channels. You’re interoperable by default. This is why we’re seeing FHIR specification emerge in the healthcare, this is why PSD2 is emerging in banking, it’s about interoperability. It makes you as a business more portable. You can choose vendors, choose software solutions, and then because your data’s synced and backed up and aggregated by default, you’re much more portable. This makes you agile, it makes you efficient in how you’re doing things. And when your teams are used to thinking in an API-first way, have all the workspaces and discoverability they need to find all those contracts that I talked about, they’re just much more efficient at innovating and then iterating upon those designs of those APIs. It reduces redundancy across your infrastructure, you’re reusing and iterating upon existing designs because you can find them. You can hit the search and you can find that you have an image API before you go building another, you have a logging API that uses a common standard already in place, all of that’s discoverable, and because you have APIs exposed at this layer, you have workspaces, it’s all discoverable. And everything, even the APIs themselves, have APIs, it makes it all much more observable. You can monitor what is going on across your API factory floor without any additional work. You can tune into all the Amazon APIs for the wealth of Amazon services that you use, or Azure, or Google. So because you’re API first, everything is just much more fluid, much more observable, much more known. Because people are educated and things are contract driven, it just works, it’s much more flexible and agile, you can do what you need to get done.

So what about the scope of this? I’ve kind of touched on a little bit of this. Think about the change that the cloud has made in our world. Cloud was the big first kind of seismic shift of API first. When Amazon EC2 and S3 emerged, they just had an API and a CLI, there was no interface. So this was very much an API-first transformation, and look at the impact it’s had on our world. Think about that with mobile, every device in our pocket, our iPads, all are using APIs to get the resources that they need. So think of the impact that mobile’s had in the last, gosh, where we’ve gone 15, 20 years now of mobile, kind of the application ecosystem around that. And then I touched on PSD2 in banking, you’re seeing the growing swells and the future waves of API first present in both banking and healthcare. I mentioned PSD2, the European Commission is API regulation saying that all banks have to have the same API, follow the same design, and those are being evolved to be more structured around the overall API operations. And they’re coming to the US, you see the CFPB in the United States preparing for a similar API regulatory set of rules. And then healthcare, if you look at the Health and Human Services in the United States, Center for Medicaid and Medicare, Department of Veterans Affairs, they’ve been issuing waves of rulings in the last year that define that if you’re a healthcare provider in these spaces and doing business with the US government, you have to have a FHIR API, which is a healthcare standard for API interoperability. So you see the coming waves of this regulatory rules, but also these standards, these OpenAPI definitions and sets of JSON Schema so we can test against these regulatory rules emerging and defining these industries. We’re seeing transportation, we’re seeing insurance, we’re seeing others follow that suit, and government getting on board and understanding more about what’s going on with APIs. And that can be good with regulatory and leadership, and that can be a challenge when you see things like the Department of Justice suing Facebook for acquiring Instagram and WhatsApp. And so these are very API ecosystem driven conversations, but it’s all a glimpse of what the future holds. The cloud and the mobile are how we got here, banking and healthcare and then the government conversation is kind of insight of where we’re going with this. But you’ve got to be API first to be able to see this, to respond to it, and be able to operate in this climate.

So what is the impact of all of this? It helps you deal with change. So when you’re API first, you’re able to address change in a much more constructive, planned way. It doesn’t surprise you as much, you’re ready for it when it happens, and you know how you got here, you have clear definition of all the last 10, 15, 20 versions, and you have the next five to ten versions planned out, you’re starting to plan this out. It’s a much more known universe, you know your resources, what your resources and capabilities are, all of your digital assets are at your fingertips, you can take action and do things, it’s all right there in a known workspace available in a search toolbar. And all of the feedback loop is available, everyone can tune in, can participate, get notifications. So the entire factory floor is a much more collaborative environment, which just allows for automation. When you have all of your APIs defined, internal, partner and public, you have all of your auth layers defined, your teams are working in workspaces and able to collaborate and work around OpenAPIs and Postman collections that define these APIs, they’re just able to do a lot more with them, they’re able to connect the dots, build workflows starting to flow around specific business use cases. And that just increases the velocity. You think of a factory floor, now think of like an Amazon warehouse with rollers where you’re rolling boxes out, think of those boxes as APIs, everything is much more fluid, teams know how to work, know how to iterate and evolve, people can just move faster, you can change APIs, you can go in new directions, and you can make money in new and interesting ways.

So it really changes the overall approach of how you look at operations if you’re API first and you’re able to do this. It’s not easy to achieve, it’s something that will take time, but you need to think about it at this scale, not just stuck in the “are we design first or are we code first,” we’ve got to be able to elevate it to new heights. Losing my voice there almost. So hopefully you can see by that list of providers that I showed you whose API first, API first is not just when you start your API in the process of when you’re planning, it’s your overall team view of all of what you’re capable as an organization, so that you’re able to respond to change. You’re already tuned in to what your customers are talking about, you have feedback loops set up, your teams are already contract literate, they can speak OpenAPI, they can speak JSON Schema, they’re effectively testing APIs, all of this collectively puts you in a leadership position, in a first or ahead of your competition. So if you’re not able to do this, you’re not able to work with APIs in this way, both publishing and consuming, you’re just going to be always following up, trying to keep up with what’s going on, where the changes are going. If you’re doing API first, you’re going to be able to lead the pack, you’re going to be much more comfortable, you’re going to know what you’re capable of, and you’re going to be able to get out ahead and actually iterate and be much more competitive.

And so really API first, to kind of close on, is not just about design or code, this is about processes, it’s about high-level business vision of APIs across your organization. And so don’t get caught up in the little down-in-the-weeds arguments. Hopefully, to bring in what I talked with Steve Wozniak about earlier, when I asked him what’s the biggest technological change that has happened, he really couldn’t point to one. He talked about the importance of people, he talked about the importance of iterations, and really the ones that have made the biggest impact are the ones that had a much more solid strategy and planning in place. And then the last 20 years, you can see across the list the companies who have made the biggest impact, API first is part of their thinking and planning. You got Amazon, you got Google, you got Microsoft being able to catch up with Azure. You just see a lot of different players emerging in existing industries as well as defining entirely new industries. I think Amazon reflects that well with transforming commerce, bookstores, very traditional existing, but then totally changing how we would think about doing business across all industries using the Amazon cloud. And you see that just continuing to play out with the news this week about the change in leadership there.

So really just ask yourself, where are you going to be in the spectrum, how you’re approaching your operations. And for resources, kind of tune into this at this scale. Really, you’ve got to be thinking platform levels, so head over to postman.com/api-platform, kind of get you thinking at this scale, at this scope, and then look at the Postman economics report to start thinking of more the business side of this and why this matters.

With that said, oh, look what he’s got to say. Anita, let me check. “Any required reading suggestions for new API folks?” So I do have a URL, I will tweet out after this, but if I can Google it, Google it nowadays. Let me see. Nope, that’s not it, that’s not it. It is API knowledge, see if it comes up. Nope, I’ll tweet this out so you have it. Here it is. It’s published on GitHub, you can find the URL, but I’ll tweet it out, it’s got all of the sites that you need to tune in, all the newsletters, everything you need to tune into what’s going on around APIs.

And with that said, I’ll leave it there, so thanks.

Thanks, Kin. Hopping over into Slido real quick, we did have a question from Jocelyn. How does API first design work in a back end for front end ecosystem, i.e. React.js? She also clarifies that a group doesn’t split our work from front end to back end, and they develop vertically, so writing an API, it’s common to do the dev first on the front end, or build the back end specifically to support the front end. Any thoughts or comments on that?

That’s a pretty lofty one, I’m going to dodge a little bit on that. What I am going to say is make sure you have a diverse API toolbox that includes REST, GraphQL, to kind of support those design patterns, because there’s not one design pattern to rule them all in a back end for front ends environment. But with that said, I’m going to dodge the rest of it, and that’s a pretty lofty one, we could do a whole nother talk on that.

Awesome. Looks like there aren’t any other questions in the chat, so thank you everyone for joining. So right now we’ll have about a half hour of a break. We also do have two sessions starting in a half hour for doing some movement, doing some guided stretching, and then starting again in an hour we will rejoin with our sessions. Feel free to join me, I’ll be part of the talk with Shank for using Postman in your workflows. Once again, thank you for joining us, thank you Kin for sharing API first. Any last comments before sending everyone out?

No, thanks everybody for coming. Feel free to find me on Twitter at Kin Lane or API Evangelist, and happy to answer other questions and help you kind of map this to the Postman platform, helping you actually realize what I’ve been talking about. I have lots of ways to walk you through that, so feel free to reach out personally. Thanks.

Thanks, Kin. Thanks everyone, have a good one.