Discover
API Evangelist Conversations
34 Episodes
Reverse
Derek Thompson of Ambassador came by for a discussion about code generation and artificial intelligence. I had began engaging with Derek's team about the importance of maintaining OpenAPI specs while generating code on Bluesky, and they agreed to have Derek come and share more of his expertise with me on the subject. I was very pleased to hear that first, they weren't focused on client SDKs, and they are generating server stubs, mock servers, and all the details that go with that. I was also very satisfied to hear of their embrace of OpenAPI, but also overlays and Arazzo. I enjoyed Derek's expertise in both API but also AI, and his focus on the developer, as well as respect for OpenAPI.
I sat down today with Marc Laventure of Scalar to talk about their API client and documentation offerings, and how they see OpenAPI as a specification. Marc's taken a slightly different approach than other API clients solutions and centering their solutions on just OpenAPI, rather than creating another spec. I feel like it is a sensible approach and can help reduce the complexity across API operations. Marc also shared his vision for their business model and where they will make money, and how they intend to balance that with their very modular and local open-source solutions--which is something I can get behind.
Juan Cruz Viotti of Sourcemeta came by for a conversation about the schema registry solution he had recently built. Juan has gone deep into the JSON Schema rabbit hole, deeper than anyone else I've ever met. His validation tooling and schema registry are providing a new foundation for enterprises to get their schema house in order. This is something Juan and I both agree is the single most foundational thing you can invest in when it comes to API governance. I learn so much everytime I talk to Juan and explore his work, and we will be working together more around the evolution of his schema registry, and API Evangelist will be leaning more into using the JSON Schema educational resources he's contributed to at https://www.learnjsonschema.com/2020-12/.
Frank Kilcommins of SmartBear came by to talk about the OpenAPI Arazzo specification. He shared the history how it came to be and how it is changing the conversation inside and outside the OpenAPI Initiative (OAI). Franks done amazing work to move the API workflows specification over the finish line, but also keep it evolving and moving forward afterwards. The specification has renewed energy with API service providers who are integrating the spec into their API guided walkthroughs, SDK generation, and testing. I am a big fan of Frank's work, and wish we had 10 more of him working at the OpenAPI, so if you are feeling like you have some spare cycles, I recommend you rolling up your sleeves and getting involved. Thanks for coming by and sharing Frank!!
Adron Hall came by for a conversation about trains. Adron and I share a love of transit and trains, who also make their living slinging APIs. Adron had recommended I read Nothing Like It in the World by Stephen E Ambrose and Empire Express by David Haward Bain back a couple of years ago, which I finally did. Then things kept happening with AI and the current presidency that kept reminding me of the stories in these books and I kepting thinking it would be fun to have Adron come by to share his view of things. I won't spoil any of his great stories, but both books and Adron's view of them, as well as his ability to apply in this moment is gold. Adron is a great storyteller and he gets the technology, but he also the business and politics of technology in a way few do, making for a very entertaining 30 minutes.
Quobix from from Princess Beef Heavy Industries came by again, this time to talk about OpenAPI Doctor and libopenapi at it's core. I knew "The Doctor" was a modular OpenAPI editor w/ governance built-in, but I didn't realize how deeply modularity is baked into it's design. This modularity allows Quobix to stitch together Vacuum, libopenapi, OpenAPI changes, wiretap, and other Princess Beef Heavy Industries solutions, but also potentially other 3rd party solutions. This modularity in API hubs, dashboards, and tools is fast becoming a common themes in conversations that I am having, and something I am going to work to leverage more as part of my work. This episode went 30 minutes because I wanted to do two separate episoides, 1) OpenAPI, 2) libopenapi, but the stories are so entertwhined we just did it back to back.
Daniel Kocot came by again to talk about the lines between our private and public APIs. We had been talking about internal, first-party, and third-party APIs back and forth on LinkedIn, and I recommended that he come by and we will have a conversation. He helped me realize that my separation between the layers was more about access, control, and velocity over just about being inside or outside the firewall and DMZ. Daniel sees this for what it is--it is about people. Lines of business, teams, tribes, and partners. Daniel has that very outside-in view of API operations, but Codecentric is being brought inside to solve the big problems for their customers. Talking with Daniel makes me realize how important it is to have these conversations about our APIs and portals, because not everyone has a handle on the nuance of what is happening at the edge of our enterprises.
I sat down with Vincent Biret, Microsoft Graph SDKs Principal Software Developer at Microsoft to talk about all things integration. I am interested in the intersection of APIs, specifications, and integrations where Vincent operates. Vincent shared his view of important role that OpenAPI plays in taming the Microsoft Graph API landscape, but specifically how it gets applied as part of producer or consumer driven SDK generation using Kiota. Vincent shared all kinds of experience and wisdom at this intersection, but he also shared a pragmatic view of the role APIs, specs, and integrations play when it comes to training LLMs, but also feeding agents deployed on top of those LLMs with the real-time resources and capabilities they will need. It was an illuminating conversation and one I learned a lot, and will be crafting more stories about over the coming weeks.
I have been wanting to sit down with Dave for a while now, but I needed to spend more time with Vaccuum to understand where it would fit into my world of API governance. I did that, and then finally got to sit down with Dave Shanley of Princess Beef Heavy Industries, and creator of Vacuum, OpenAPI Doctor, and other important OpenAPI tooling. I finally got the full background of why he felt Spectral was falling short when it came to linting our API specifications, and it was much more than just about speed. I left our conversation with a head full of ideas and a bunch of notes on what is next for API governance and rules, and need to have Dave back talk about OpenAPI Doctor, libopenapi, and his other great work.
My friend Emanual had tagged me in one of Reza's posts on LinkedIn about API integrations being dead, so I invitied Reza to come over and explain more about what he meant. I knew the title was bait, but I was interested in hearing Reza's argument and after the conversation it is clear that he's done a lot of thinking at this intersection and wasn't just adding to the AI hype. It was interesting to hear the reasoning for signalling a shift in how we see and abstract away the work APIs are doing, and it was validating to hear that governance will play an important role in KILLING API integrations. ;-)
Ben Hutton of the Guild came by to talk about his recent LinkedIn thread about APIs vs SDKs. The topic is an evergreen one that brings out all of the opinions and I enjoy talking with Ben about it to get his pragmatic view of things. Ben has a lot of experience as a software engineer and working on the JSON Schema specification, which I think gives him unique perspective on what is needed when it comes to integrating with APIs. Ben was on my team at Postman, but we are now collaborating on helping people understand the importance of getting their enterprise schema house in order. Thanks for coming by Ben, and I am looking forward to further unpacking what enterprises are needing from schema to SDKs in future conversations.
Lorna Mitchell, OpenAPI Specification Maintainer with the OpenAPI Initiative, and overall API experience expert came by again, this time to talk about the intersection of OpenAPI extensions and experience. I would say our conversation also intersects with the last conversation I had with her about OpenAPI overlays, but focuses on the need to extend the spec to meet the needs around specific experiences, which may or may not be better addressed with overlays. It is all a very fascinating and ever evolving aspect of the OpenAPI spec world, and I am thankful to have someone so close to the spec to talk through and learn from at the intersection of OpenAPI extensions, overlays, and API experience.
Claire Barrett, Digital strategist at APIsFirst came by to talk with me about the realities on the ground with APIs in large enterprises and the increasing chatter regarding the return on investment APIs. Claire's view of things is what API service providers should be tuning into when it comes to aligning product with engineering, treating APIs as a product, and making sense of the real world things business leadership are looking for. I'm thankful for Claire's perspective, but also all the work she does around APIDays, and Women in APIs, but also just being outspoken about the business value of being API-first.
Henry Calvert, Global Head of Future Networks at GSMA came by to talk about the GSMA Open Gateway, a suite of APIs the GSMA Open Gateway global initiative aims to drive the exposure and monetization of telecommunication networks through APIs and federation. The GSMA launched the Open Gateway APIs under the Linux Foundation in a project called CAMARA, and you can find all the OpenAPI specifications for the APIs on GitHub. The GSMA looks to have taken a pretty savvy balance between what developers are looking for, telco business leadership, but also government regulators, making for another interesting attempt to modernize telco networks using a standardized API-first approach.
Lorna Mitchell, OpenAPI Specification Maintainer with the OpenAPI Initiative, and overall API experience expert came by to educate me (us) on OpenAPI Overlays, helping contrast with the core OpenAPI spec, as well as with Arazzo Workflows, sharing how it will help bring more stakeholders into the API lifecycle and contribute to better API experiences. Lorna is a well spring of knowledge when it comes to OpenAPI, but also other specifications, as well as Spectral and other approaches to governing APIs, and she'll be coming back shortly to help educate us all about the intersection of overlays with extensions and how it all will change API experience.
Greg Dennis who was on my team at Postman, and part of my master plan to spend as much VC money as I could on open source API technology, came by to share his expert view on the diff between HTTP APIs and programming language library APIs. Greg is one of the caring souls who are tending to the JSON Schema specification, and has extensive experience developing and maintaining his .NET JSON Schema library--json-everything. Greg is learning more about HTTP API design these days, but I find his view of the art of programming language library API maintenance important, and something that helps expand, color, and shape my views as an HTTP API craftsperson.
My friend from Postman days Ian Mai came by to talk about addiction and impulse control with me. This isn't your average API conversation, but neither is my podcast, and I am all about sharing my own struggles, while also giving friends a platform to help others with their battles. I appreciate Ian's honesty in his own struggles with addiction and trying to find balance, and wanted to learn more about why he left Postman, and why he said he was leaving tech. I don't see Ian as leaving tech, I think he'll continue to help us all find our way, and be there for anyone who hits the wall or drives into the ditch, as most everyone will experience at one time or another. I always cherished Ian's energy, and think this is the perfect role for him and his boundless enthusiasm.
I recently sat down for a conversation with Luke Seelenbinder, Founder & CEO of Stadia Maps to talk about taking on Google Maps with a more sensible and affordable mapping solution. As I learned more about the Stadia Maps journey I found ourselves talking about product-led motions for companies, and what the meaning of APIs as a product was. Luke and Stadia maps reflects the real world businesses who are doing APIs that I am looking to talk with, because they aren't playing in the startup hustle, and actually are building a real-world business that is in tune with and responds to actual market forces.
I was happy to have Raymond Camden, Developer Advocate at Adobe come by for another conversation. Raymond was on Breaking Changes back in the day, and I've been a follower of his work for well over a decade. He provided his obligatory plug for Adobe APIs he is an advocate for, but what is really motivating him was his new work at the intersection of API and AI. I don't have the time and budget to go to deep on AI, so I enjoy learning from someone who is as curious and pragmatic as I am about new technologies, a conversation that left me with some ideas of how I am going to use not just ChatGPT, but also Google Gemini for some of the API profiling work I am doing.
The opinionated and deeply knowledgeable driver of API specifications and VP of Developer Experience at Redocly, Lorna Mitchell came by to share some knowledge on Redocly CLI with me. I have made an executive decision to not have API service providers on my podcast, opting to speak with API producer and consumers, but Lorna transcends her role at Redocly. Lorna is part of the TSC for the OpenAPI Initiative (OAI), and has deep experience across the specs, but more specifically across approaches to lint these specs--this is the knowledge I am looking to tap into during our conversation.



