Talking APIs and Description Languages with API Evangelist Kin Lane

Kevin Montalbo

All right. Joining us as always, all the way from Australia, is Toro Cloud CEO and founder David Brown. Hello, David. Good morning!

David Brown

Good morning, Kevin.

Kevin Montalbo

All right. And our guest for today is the Chief Evangelist for Postman and is also known as the API Evangelist studying the technology, business and politics of the API lifecycle, having worked with startups, enterprise organizations and government agencies when it comes to their API lifecycle strategy. He has worked for the Obama administration as a Presidential Innovation Fellow and with the European Commission and EU on API related policy and practices. Ladies and gentlemen, I am proud to present our guest for today, Kin Lane. Hey, Kin. Great to have you on the show.

Kin Lane

Hey there, thanks for having me! Happy to be here.

Kevin Montalbo

All right, so let's jump right in. So, apart from the achievements and the whole resume that I just gave out there, we wanted to congratulate you on becoming the Co-chair of the OpenAPI Initiative Business Governance Support. So, what do you hope to accomplish at OpenAPI?

Kin Lane

Yeah, I know, thank you. That's definitely a meaningful moment for me because I've been involved in the specs since early days, you know with Tony, building out Swagger and really helped play a role in getting it into the Linux Foundation. And so, Isabelle and I are co-chair. So Isabelle, from 42Crunch and I, we both had a lot of interest in the role, but neither of us wanted to do it all by ourselves. And we complement each other so well. We said, "Hey, why don't we throw our hat in the ring together?" And I'm very thankful to have her in a supporting role. So we kind of laid out our original pitch when we were kind of politicked in getting the role and talking to folks, but also just kind of what we want to see.

And so we feel pretty strongly right now that the OpenAPI initiative to date has been really about kind of a defensive stance of the spec itself. Like we've gotta just stabilize the spec. We've gotta get it moving forward, get it to version three, move it beyond the Swagger days and kind of defend it against its other competing specs as well as somewhat service providers, tooling providers and whatnot, and we feel like we want to kind of reverse it. Now is the time it's stabilized. The spec is moving forward towards 31 now and fighting harmony with JSON Schema and other specs. So, we really feel like now is the time that we need to kind of shift into higher gear when it comes to reaching out to other specifications. So that support of JSON Schema that we talked about, Async API, and then part of my Postman work. Postman Collections kind of fit in there nicely.

So, really, working well with other specifications, I would throw GraphQL into the mix there as well. And then how are those applied in specific industries. So when it comes to healthcare, financial, travel, so really trying to take kind of an outward facing motion when it comes to reaching out to specific industries and how they're using OpenAPI. And then I would say the other piece is really helping bring more definition and clarity to what services are available, what service providers exist that are using OpenAPI, such as yourself, and then also the same for tooling. The OpenAPI tries to take a neutral stance when it comes to services. Not playing favorites, which is sensible and, you know, works well. But we also got to strike a balance between how do we push forward adoption of the spec among service providers? How do we get people to be more open and share their specifications rather than keeping them hidden? And so the main areas are multi-spec, multi-industry and then really kind of bring some coherency to the services and tooling around the specs.

David Brown 

Kin, I would like to hone in on that multi-spec concept. So at the moment, the OpenAPI initiative, as you say, is all about the evolution of the Swagger definition and making it its own thing. But you mentioned a few other competing formats, like JSON Schema, GraphQL, Async API. So are you talking about bringing them into the fold? Are you talking about making some sort of complementary integration between them? How do you see it working?

Kin Lane

Everything's on the table. I would say the OAI is a home for other specs. I think that's on the table. That's one of the conversations. It's available to Async and JSON Schema. GraphQL is already in the Linux Foundation in a separate group. So, I would say it's kind of all the above. It's how do we work better, interoperable between existing specs with their own governance already in place, make a home for other specs that maybe need a governance. And I would say, Async API right now is currently looking for a home and kind of courting and talking to Linux Foundation, Apache and others about finding a home. The OAI is on the table. That conversation is continuing. Same for JSON Schema. You know, JSON Schema is still in draft mode, but it’s definitely become a specification means baked into both OpenAPI and Async API as a sub-specifications, but its adoption across the enterprise is pretty clear. As it matures and grows up here, where is it gonna live? That's on the table.

But really for me, the most important part is how do we start working together? Ensuring that the specs are supporting each other? You know, like, we have a project right now that the OAI is looking to do involving JSON Schema documentation. And I know Async API is very keen on this as well. People want the JSON Schema documentation to keep up with the latest draft. That's right now, but also just support the need because OpenAPI has JSON Schema support needs. Async API has JSON Schema support needs. So the docs have to be really good. And the OAI can help fund that, help make that happen. Async API can help fund that, make that happen.

And so how do we fund those cross spec initiatives? How do we find projects that make them happen? And then I would say, "How do we stay competitive but do it in a more collaborative way?" If I could say that and I'm calling out specifically, GraphQL and OpenAPI. How do we be more honest and upfront about "Hey, these are two very powerful specifications for very different but overlapping needs." And how do we not say, "Oh well, GraphQL is going to replace OpenAPI," or "OpenAPI is the one." How do we say, "Well, they're both valid in a diverse API toolbox," and make sure we're approaching it sensibly.

David Brown

Yeah, because you've written about this on your blog before, right? This mindset of "GraphQL is better than OpenAPI" or vice versa. And you're like, "Hey, guys, it's not about which one is gonna win the war here. Let's work out the advantages and with the use case for each and how they can work together and compliment each other."

Kin Lane 

Yeah, that's super important. I'm a database guy. I mean, databases go back, way back to the eighties to date myself. You know, that's my first job. That's when I got into API. So I get GraphQL and I love GraphQL. I think it's super powerful, but I don't think it's a replacement for REST APIs and I don't think GraphQL as a schema is a replacement for OpenAPI. I think they both have their places, and I think it does, similar to the linked data folks, the hypermedia folks who came, they kind of come onto the stage with this aggressive stance like, "Hey, we're the best. We're going to replace what came before us," and I get that. I mean, that's a kind of bravado that we have in the text base, but it's not conducive. You know, I've been on a lot of projects that should have been GraphQL implementations that didn't, because of some kind of over aggressive positioning and stance. And they were just like, "Well, we really don't want to get involved in GraphQL because it just sounds like it's a trendy kind of thing that we might regret." And I'm like, "No, it's actually a good tool," you know? So it's tough.

David Brown

You also talked about servicing specific verticals - healthcare, banking, all the rest. Tell us a bit more about that. What's the vision behind supporting specific verticals?

Kin Lane

Yeah, so I mean, every industry that's been transformative over the last 2, 300 years has faced regulatory positions. You know, rules and regulations coming down from governments to kind of stabilize and as a space, grow. Think telecommunications, automobile industry, these all face that. So that's what's happening to technology. Right now, we see a lot of that. And so, the industries you see that happening in are the most heavily regulated ones already. So healthcare, finance and travel are kind of the tips of those spears. And those are the ones we see API regulations emerging. So PSD2 banking in Europe, and then we've seen other countries emulate that policy. So here's PSD2. It's how you define your payment APIs, your bank account APIs and standardize those across Europe, UK. And then we've seen that in Southeast Asia and other places adopt that. Now, in the US the CFPB, the Consumer Finance Protection Bureau is adopting a similar [regulation]. They just announced that they're going to do that.

So, the federal government in the US says "You need to have APIs, eh?" and those APIs need to reflect this standard. And that standard could be described as OpenAPI. So PSD2, you could describe as using an OpenAPI. And so you see that in healthcare as well. There's what's called the FHIR API standards, HL7 FHIR. And it's a healthcare standard to ensure interoperability between healthcare systems and in the US, the Center for Medicaid and Medicare and Health and Human Services has mandated several waves over the last couple years that if you want to do business with the US Government when it comes to healthcare, which is 60% of the healthcare in this country, I believe, roughly, that you need to have an API, and it needs to follow this standard. And again, you could define that standard as OpenAPI.

And then the same applies in travel. There's the OpenTravel specifications for the travel industry, airlines, hotels, activities, all of that defined as a common standard, which you can then articulate as OpenAPI. So the Venn diagram is just pretty natural there, that you have these emerging regulations and rules. You have these industry specifications that could be described as OpenAPI. They can also be described as Async API and JSON Schema. How do we, you know, move all of those conversations, make sure we're doing it in a healthy and logical way? And then how do we do that in other industries that aren't those three?

David Brown

Like you say, that the industries already have the option to describe those APIs in OpenAPI or other formats. So what would be the OpenAPI’s initiative there? Would it be to approach those governing bodies of those industries and promote the OpenAPI description format to those industries so they try and get those industries promoting the adoption of Open API as the description format of choice?

Kin Lane

Yeah. I mean, I would say that, but even before that, just showcase that which is already happening. I mean, FHIR, HL7 FHIR, they're using OpenAPI to define it. They're using JSON Schema. Same for PSD2. You can find OpenAPIs, you know, from the French government, the German government, the UK government. So they're already using OpenAPI. Well, the UK is a member of the OpenAPI, Netherlands has adopted OpenAPI as official government standard. So there's some of that, but there's not really any feedback loop or two-way street there between the OAI and these industries. So yeah, go out and engage with the folks who are already doing things. Go out and engage with industry organizations who maybe aren't already OpenAPI fluent and building relationships there and figuring out what they need. Let's just set up a feedback loop and let's have dedicated reps at the OAI to help be the kind of ambassadors for these industries and help do some of the legwork and see what comes back through those feedback loops.

David Brown

Interesting. You mentioned JSON Schema a few times in Postman's 2020 State of the API report. You found that JSON Schema is the dominant API specification, or 75% of respondents using it. OpenAPI came in at 27%. You also said that OpenAPI has some sort of support for JSON Schema. So can we talk about the distinction here, were you talking about respondents saying they're using JSON Schema over saying OpenAPI supports JSON Schema? Can you run us through that?

Kin Lane

Yeah, it's a tough one I think we need to keep talking about because I'm always fascinated by helping people who are unaware of this and how long I was unaware of it, too. I didn't really fully grasp, but so let’s start with JSON Schema. It's a format for defining objects. JSON, XML, CSV, YAML any object that you can, it's called JSON Schema, unfortunately named. You can use it in the YAML formats, and you can use it to describe other formats. But JSON is, I think, the most common. But you use it to describe your objects. So you have, you know, a product. You know, the name of the product, the description and the pricing, the brand, those are all properties of that object. You have a product, and you could describe that with JSON Schema, and it provides a machine readable way that says, "Here's the object. And then here's its properties. And then here's a handful of characteristics about those properties," meaning it's a number. It's a string. It's a date. So, it helps you model your objects. And these are the objects that get passed back and forth through APIs. So in a RESTful or Web API, which is described as OpenAPI, that JSON Schema could be posted to an API so it could be part of the request of an API. Or it could come back as the response. So if I'm calling a product’s API, I'm getting back an array of product objects defined as JSON Schema. If I'm adding a product, I'm gonna post that object. So really, JSON Schema is the most critical because these are, you know, this is our data modeling. This is how we're kind of defining our digital assets. We're not talking about access to those digital objects. Yet we're just saying these are, you know, these are the digital resources that we have laying around or these are the digital capabilities of our organizations. We can send email, we can send SMS and here's that object.

Now why it's the most popular is for many reasons because there's not a lot of competing standards for modeling and data modeling. There are, but they're more database oriented. They're less API-oriented. And then most people don't even, API providers, in my experience, don't see the access. They see the API is about the resource, that object being, you know. So, it's about the products. It's not about the product access through the API. And so, a lot of emphasis and rightly so, the value is placed on the object itself rather than a well-designed API providing access to that object in a request-to-response way or in a published-subscribed way, a message or the event driven way that would be described as Async. You could use Async API.

So with that said, you have Web APIs, that request and response. I can use JSON Schema to describe what gets requested and what ends up as the response and OpenAPI describes that access. So OpenAPI describes the path for the products API. All the parameters, all the details. And then it has a reference to JSON Schema that says, "Here's the product you'll get back as part of the response," or "Here's the product you can send as part of the request. And so JSON Schema is a subset of OpenAPI. You describe all of your objects as part of your API using JSON Schema. You just wrap it with OpenAPI and the same for Async API. So Fran, creator of Async API modeled it after OpenAPI. It's a sister specifications. But rather than just describing request and response APIs or HTTP APIs, you could describe a TCP, MQTT, Kafka NATS, a more, kind of wider, spectrum of protocols. But they tend to be more pubs of event driven, message-driven designs of a piece for access. And so JSON Schema is this subset of both OpenAPI and Async API and core and key to the modeling that occurs around those access to those APIs.

David Brown

Are you familiar with the common data model promoted by Microsoft and Adobe?

Kin Lane

I am. I'm familiar with it. I wouldn’t say I'm an expert in it.

David Brown

Yeah. So we've been doing a lot of work with the common data model, which is a model for defining data entities like a contact entity, older energy, these objects. And we've built a product on top of that called Negroni. So here's JSON Schema specification to define those objects. And give people a UI to build these objects or extend existing objects and then use the OpenAPI specifications to create a service to be available to create a database schema to be able to read and write this JSON Schema.

Kin Lane

Nice.

David Brown

So, exactly along the lines that you were talking about.

Kin Lane

Yeah, I would love to. I'm a big fan, supporter of JSON Schema, definitely working with Ben and then try to envision the future. But I would say, you know, I was part of the RAML working group for a number of years, and I still have regular conversations with them, and that was a pretty superior approach specifications to data modeling and as well as the access by APIs and whatnot. So I'm really big on their being competing standards and I would like to see OpenAPI like Async API does, be more compatible and versatile with other specs. And this is, I would say, one of the things that Isabelle and I want to focus on is extensions. There's a lot of extensions that have emerged and study those a little bit more when it comes to theirs, like Service Level and Gateway and CodeGen and other types of extensions of OpenAPI that have emerged, some of those are related to the data modeling in the JSON schema. Some of them are not, and then the concept of overlay. Do you either extend the specifications or can you overlay something to the OpenAPI? Does it need to not be actually part of the OpenAPI spec? Can you just, like, augment OpenAPI with it?

And so I'm really keen on pushing forward conversations around competing specs, extensions, overlay in a multi spec around, not just siloed and thinking, "Oh, this should all live within the OpenAPI spec." No. How do you create a kind of buffet of these specs that you can then overlay to OpenAPI or Async? You know, think of WebSockets API. You know, you may start with HTTP request-response API, get a header. "Hey, switch over here to a pub sub and web sockets." How do you define that using OpenAPI and Async? But then how do you overlay or extend those in a way that they work together? So, yeah. I think there's a lot of opportunity on this front.

David Brown

You've got your work cut out for you. You must be being bombarded by people asking you how they can collaborate and extend with OpenAPI.

Kin Lane

Well, I find, for the most part just studying what people are already doing. Because I did a story last week on API Evangelist just out of some research I was doing, you know. Looking at AWS's, Microsoft's, and a handful, I think 14 total service providers and what their extensions are because they actually have a page dedicated to explaining their extensions. And I just learn a lot from that. So I think, you know, people just use OpenAPI, do what you do with it, and let's come up with ways that you can communicate that out. We'll just study that in real time as it's happening.

David Brown

So there's a lot of API description formats, perhaps more. We mentioned RAML and it has been consolidating particularly for RESTful APIs on OpenAPI. But Postman also did, in part of this 2020 report, cited obstacles for adoption of APIs and 52% decided the number one obstacle for adoption of APIs was the lack of time, followed by a lack of knowledge of how to do it, the 36%. As an industry, the one ourselves included producing tool sets for API development and deployment, how can we help address these obstacles?

Kin Lane

Yeah, So I mean that those two kinds of things represent a lack of prioritization from leadership of these organizations. So, lack of prioritization of the API’s itself, as well as the lack of prioritization of their employees learning these new technologies learning what an API is, what OpenAPI is, how these things work. And so we've got to do a better job. And I think the OAI as well as the other specs as well as service providers such as both of us. You know, how do we work together to better invest in documentation collateral content that educates around, you know, APIs because there's a shared value, a shared benefit here and I've seen it because I'm API Evangelist. I started in 2010 and I am at 5000 blog posts now over the course of a decade, and really with a focus on educating people and educating people who are developers but also not developers. Trying to get to that leadership factor like this should be prioritized. And this is why it's not because it's just some new vendor solution or some new trend. It's actually fundamental to your business.

And so how do we convince leadership of that? But then all the way up to leadership, how do we educate people about good API design? Why simplicity and HTTP matters, why interoperability matters and having shared specifications so we could do interoperability much cheaper in a much more automated way. And so, we all got to get together, and I'm trying to do this as part of the OAI, but we have a project that's outside of the OAI because I'm trying to make it multi-spec and multiservice provider. It’s called the API Specification Toolbox. But how do we create blog content independently of any domain or destination? But just about OpenAPI, you know, literacy and education, Async API, JSON Schema and then how do we publish and syndicate those blog's where they need to get the widest reach? So we're educating. How do we do that with white papers? How do we do that with podcasts and web content or video content? How do we do it with, you know, other areas? A shared newsletter, maybe? Like for this podcast, I mean that's why I responded to you guys because I'm here as a personality to be on these. But then how do we, as you guys bring every cast of character you know, a personality on, how do we help amplify? You know, if you guys were talking about specifications, which I know is core to your business, how do we as a community highlight that? Even if I'm a competitor of you guys, how do I see the value in tweeting your podcast and tweeting it out? And how do we have this kind of shared sense of the API community in a way and enrich it and invest in it, knowing that it's gonna make all of us better even when it comes to competing and so you know, then it was Sam Ramji from Apigee when they IPOed, or maybe it was when they IPOed or got acquired by Google, he's like, told me "I've always really appreciated what you do as API evangelist because you're educating people. And we couldn't always prioritize amongst our investors spending money on educating the space about what is an API and why is an API. You always did that." He's all, "And then if you look at our budget as you know, we go public and transparent, that you have to share that, education ended up being a massive part of our spin because it's supercritical, even though throughout our journey, we had to fight tooth and nail to allocate that money invest in money." And he's like, "You, as API evangelist, always understood this and knew this was a default and just did it," you know?

And so that's what I really kind of want to bring to the API Specification Toolbox and how to as a community of service providers, tooling providers and specifications, how do we get better at shared storytelling, supporting each other's work, being on each other's podcasts, amplifying each other's podcast.

David Brown 

So I think that educational process is gonna address the lack of knowledge aspect of that obstacle to adoption. Lack of time, though, is a different issue, right? So I'm wondering where the tooling itself needs to improve. Maybe more automation is required. How can we address that lack of time aspect on those tooling providers?

Kin Lane

We should have OpenAPI specs for all the services that we need out there and those shouldn't be hidden.

Well, part of that is we've got to educate the leadership because leadership carves out and allows for workers to have the time, so that's a big piece of it. But I would say we got to demonstrate that "Hey, if you embrace OpenAPI and do OpenAPI well, you're going to be doing APIs better." Meaning you're going to be designing, delivering a more consistent APIs. But then you're gonna be integrating. And I would say this is just the next iteration or evolution of CI/CD is, interoperability shouldn't be this hard, you know. It's like we should have OpenAPI specs for all the services that we need out there and those shouldn't be hidden. Those should be publicly available, consistent and up to date and then the awful layer on that should you know, we've got a lot of. It's been a while since, we need to invest more and not just a lot. But I mean, JWT reflects this, you know.

But we've got to invest more and kind of the next gen of authentication and identity and access management over this, so it's not as hard for me to authenticate with all the services I need. And so we demonstrate the leadership, APIs matter, why they matter. And if you're doing them well in a machine readable way like this, it benefits your company and everyone else's companies as well. And we got to get people over that fact that, if I have a catalog of up to date open APIs for all the top services out there, I share that somehow. You know, giving benefit to my competitors, You know? No, like, sure you are, but it's gonna benefit you even more. You're gonna be more agile, nimble and flexible. You're gonna be able to pivot. You're gonna be able to respond to business changes quicker. And so, that lack of time if you do APIs as well, that lack of time shrinks because you're quicker. You're faster, your teams well-educated. They know what to do. You can respond to critical changes. You can out compete your competition. You could do what you do best as a business rather than just the mundane, repetitive things that we have to face when it comes to continuous deployment and continuous integration. And, you know, the interoperability amount of preaching to the choir with you guys. It just needs to be a no brainer. Most people don't care about specs, don't care about the granular details. They just want the business connection to work. And that's the way it should be across the board.

David Brown

We’re coming to the tail end of the podcast, so I just wanted to quickly get your opinion about the future of APIs. In this podcast, we talked about the future of APIs, covered areas like automated API. Discovering connectivity by defining an API, by the domain that it controls. We also discussed how machine generated services from an API schema, including OpenAPI or Postman Collections can kill the concept, having connected where you can generate services on the fly. What about you? What do you see in regards to the future of APIs?

Kin Lane

All of this just has to get easier, which means with the future, it’s just further investing in what we already know.

I mean, it's easy to intact the kind of this, to have this futuristic, moving fast, "always forward" view of the landscape. My view, after 30 years in the tech space and then 10 years exclusively on APIs is much more slower. Wider? I wouldn't say slower is the right word. It's not the precise focus. It’s "Let's invest in more of the things we're already doing. But doing them better," you know? Discovery is not new, you know, there's been service discovery for a while. It's not new. We've got to improve it, you know? And you see things like this happening. My friend Z, who came from Apiary, just got some funding for a new kind of AI discovery service. I've been working on discovery stuff for quite a while. I have my own specification APIs JSON that allows you to describe API operations and not just the API, but the business of that API, the onboarding of the API, the terms of service for that API, all those other things that are critical to integration that can become friction points and have to be machine readable. If we're gonna automate all of this, we have to understand the pricing of the API we’re integrating with. If we're gonna automate it, we're gonna have to understand the terms of service, the privacy policies, all of that in a machine readable way.

So the future of APIs for me is just doing what we already do. But doing it better, abstracting away the complexities so that business users can move faster with APIs. You know, I'm a big believer that everyone should understand that APIs exist, because you should never buy a SaaS solution or software, anything that doesn't have an API as a business because you're just locking yourself in. But business users and leadership should understand the technical details of oAuth and OpenAPI. But they should understand OpenAPI is better for their business, better for their connectivity, better for their interoperability. And so, really, the future is about making, you know, making sure it's all visible, like you can see all the moving parts of the machine. It's better defined using specifications, more plug-and-play and interoperable.

But, you know, there's certain things about APIs that are still difficult for me and I'm, you know, an API guru, whatever. It's like, why is it still so hard to connect to some APIs? You know, it's just really difficult. It shouldn't be. And that's not because of technical. That's because of business and perception around competition. You really, you know, your partners. It's easy to onboard frictionless but the public API is meant to be difficult. And not that those are always conscious, sometimes their subconscious. But for me, the future is like it's just better defining our life cycle. Better defining the services that we use depend on internally and externally. When it comes to discovery, like, can you find all of your APIs as an organization? I haven't been to one enterprise organization that knows where all their APIs and have them defined in the catalog. I don't know one organization that says "Man, that sunlight starting to really shine on me." The one organization that knows all the external services and APIs they use. So the Dropboxes, the Twitter APIs, the you know, Office 365 API. There's no organized way for organizations to go, "Here's the resources we depend on. Here's the capabilities we depend on."

So discoveries can't get more complicated. It's gotta get easier. And so the future is more about, it’s gonna be less technical, less of the geeky stuff. I mean, like service mentioned things like that are great. Like, I'm a big believer in the reliability and stability of API circuit breakers, all of that. There's a discovery component to that. But these are very geeky, technical things and same with Kubernetes and containerization. All of these things are critical infrastructure. You know, when I started in 2010, it was all the Twilios and Sendgrids and Stripes. The alpha tech companies I was talking to. By 2017, I'm talking to banks and insurance companies and healthcare providers. So, everyone's doing APIs now, as we move into the future, it's just gonna be about how do we simplify that? How do we make it have mass appeal? Mass adoption? It can't just be about developers, and it's got to be about non-developers and business users. And we're seeing this with Postman as you know, a lot of our growth in adoption is amongst sales and analysts who are using collections to get data out of systems that they can't get through an interface. We're seeing more product managers and people who are leading groups and leading teams in there.

And so you see APIs or something that's being used by the average business person. And so all of this just has to get easier, which means with the future it’s just further investing in what we already know. I know it's not sexy. I know it's not like, you know, sci-fi futuristic. What's cool? What's next, you know? But it's the reality of it. We’re coming out of the Wild West, regulations starting to hit. We've just got to really kind of dial things in and get more standardizing, consistent in what we're already doing.

David Brown

I think that standardization, adoption and maturity of the API landscape is, perhaps, sexy for corporates because that's what they want. You know, they don't want cutting edge. They wanted to stabilize. They want it to settle down and become easier. So as techies we don't see it as particularly sexy or exciting. Maybe it's more practical, and it is more exciting for the corporates.

Kin Lane

The future of APIs for me is just doing what we already do – but doing it better.

Well, with that said, I think more, you know, I'm seeing API lifecycle organizations. You see this with API-First things is that, when an API comes to life, there's not just developers at the table bring into life. There's other business stakeholders part of that conversation from day one, and I think that's the sign of the future. And what's to come is we need, you know, we don't need us techies always leaving all of these conversations because we don't get the business reality a lot of the times, and we're doing it for the sake of the tech. And so we need that tempered-by-business value, and I get a lot of people who say, "Well, we've already done this before in the SOA time, you know?" It's like I hear that constantly. Yes, but we weren't honest about some of the business and other implications. And that's why those things failed or fell short. Because as developers, we saw the perfect technical solutions. What wins? And that's not the case. I mean, I think I could say this honestly. Between RAML and OpenAPI, RAML’s a superior specification. OpenAPI, I’m sorry. It just is. But it didn't win, and that reflects the wider API space to me is, the best product doesn't always win. And I think we've got to just be more honest about what those influences are.

David Brown

I'm old enough to remember Betamax versus VHS.

Kin Lane

Yes, totally. Great example.

David Brown

Alright, again. Look, great practical advice. Pleasure to have you on the podcast. How can people follow you, keep in touch with what you're writing and talking about.

Kin Lane

I mean, I'm easy to find. My name's original. So K-I-N, Kin Lane is pretty easy to find that there's only one other gentleman who lives in Hong Kong with the same name and he's not doing API. So, you know APIevangelist.com is kind of my, you know, where I blogged. It's what I'm known for. You can find me on a Postman.blog.postman.com, but on Twitter, Kin Lane or API Evangelist, you'll find me there. I'm pretty, pretty prolific. Those were the main channels you're gonna find me.