API Evangelist
API Evangelist is about making sense of the world of application programming interfaces, or simple APIs. APIs have become part of every layer of our Internet connected world over the last 20 years, and this is my research project into understanding what is happening. As of 2019 I am also the Chief Evangelist for Postman, but I still use this site in the same way I have since 2010, as a workbench for what I am working on each day. Providing me with a very public way to work through my projects, while helping others see the world of APIs in different ways, and hopefully learn more about how APIs are being applied across our world
This isn't meant to be a blog in the traditional sense of the word, and you should think of it as Kin Lane's personal notebook that he is fine with others reading. Once you spend time reading my work you will better understand that this is my souning board, helping me work through my ideas, and I am not doing this for page views, audience size, or other metric. However, after over ten years of doing this I tend to have a regular group of folks who are tuning in and providing commentary via Twitter, GitHub, and other channels.
Stories > Code
23 Jan 2022
I have learned so much from my partner Audrey Watters over the twelve years I have been with her, but one of the most powerful concepts I have picked up from her and ran with in my own way is the importance of storytelling. Not just the importance of it, but really that it is the only thing that matters, and will almost always trump very logical ways of seeing the world that are ubiquitous in the tech sector. A good story will get you further than any perfectly written code or applications, and in a world drowning in technology, stories are not just how you stay afloat, or get ahead, but it is also how you stay sane in all of this. Over the years I have fused my approach to writing code with my approach to storytelling, producing quick and dirty solution solutions for each situation I find myself in. There are many examples of my approach visible on the web in any given week, but a “production” you will keep seeing throughout this year centers around OpenAPI listing rules in service of what is known as API design governance. One of our competitors in the API space created a very forward thinking approach to listing OpenAPI specifications called Spectral, which allows you to create little JSON or YAML rules that can be applied to “govern” the design of each API using an OpenAPI artifact. Spectral is leading the conversation when it comes to API design governance, but after much studying I found one area that I can both contribute to the open source solution, while also carving out my own slice of the API design governance conversation. Simply by focusing on the storytelling involved with each individual rule, rather than efficiencies involved with actually applying rules. As with most layers of technology, it can get pretty complicated and overwhelming to make sense of the potentially hundreds of API design governance rules you’ll...[Read More]
Knowing Where Each Version of Our OpenAPIs Are
23 Jan 2022
Almost every enterprise organization I know struggles with knowing where all of their APIs are. There are always shadow and invisible APIs that exist across the enterprise API landscape, and at with the pace of change that exists within the average enterprise today, this is something that will continue being a reality for most teams. Adding to the confusion across this reality, most enterprise organizations also do not know where each version of their APIs are, and while there may have been a significant amount of work done around defining OpenAPI or other artifacts for APIs, there rarely is consistent investment in linking together multiple versions of OpenAPI definitions. Resulting in OpenAPIs being spread across servers, Git repositories, and the desktop of developers, leaving us not knowing where each version of our OpenAPIs actually reside, rendering the unavailable for use in automating change management across our API operations. OpenAPI provide us with a machine readable way to articulate how change should be defined for each API, and the ability to automate across different versions of our APIs, but if we don’t always know where our APIs are, let alone the OpenAPI artifacts for them, and do not possess any way of articulating where each version of an API exists, we are left unable to govern and direct change across API operations. For example, if I want to detect breaking changes across a single API, I will have to have the context of where the last version of OpenAPI exists, knowing the branch, path, or specific location of each API artifact. To be able to effectively diff across multiple versions of your OpenAPI, you have to not just have common approach to versioning and storing your OpenAPIs, you have to have a common and machine readable way of articulating where they exist. OpenAPIs open up a whole other world of possibilities when it comes to discovery, governance, and managing our APIs, but the next frontier of...[Read More]
Detecting Breaking Changes Across API Versions
23 Jan 2022
API governance is still very much mired in the design phase of evolution, focused on the consistency in design of a single API. And while we all have a lot of work to onboard the enterprise masses when it comes to applying API design governance pragmatically, leading edge API service providers have begun shifting investment beyond just design, and focusing on more operational level concerns across many different APIs, or multiple versions of an API. You can see this present in the recent release of optic-ci from Optic, which allows you to detect breaking changes in the CI/CD pipeline using their open source approach to API governance that leans more in the direction of operations governance than design governance. optic-ci plugs into your Github pipeline using Github actions, Versions - Pulls the previous version o your API definition to compare alongside your current release. Diff - Conducts a semantic diff using both versions of your API definitions to understand what’s changed. Breaking - Looks specifically at what has changed and determines whether or not they are breaking. Pass / Fail - Passes or fails your pipeline run based upon whether or not there is a breaking change present. Source - Shows you the source of the breaking change, allowing you to know location within definition. This CI/CD pipeline solution for detecting breaking changes in APIs goes beyond the testing of each API contract, or even the surface area of the API releasing and considers what has occurred across two separate versions of your API. Taking into consideration not just the surface area of your API but also beginning to see your APIs as something that is changing, allowing teams to embrace change in a standardized way. It is difficult for teams to get a handle on what is happening across many different APIs, but it becomes exponentially more difficult for teams to get a handle on the different rates of change happening across many APIs....[Read More]
Beyond API Design Governance and Moving Towards Operational API Governance
23 Jan 2022
When you talk about API governance, 90% of the people you encounter will assume you mean the governance of a single definition of an API, and not multiple versions of an API, or the operations and lifecycle surrounding an API. Leading edge API governance solutions like Spectral>a help you effectively codify the patterns you are using to define and design consistent APIs across your operations, but until recently there hasn’t been much in the way of helping you governance change across APIs, and how you deploy, document, test, and operate your APIs. API design governance is critical as part of API operations, and we have a lot of work to do when it comes to getting API teams applying consistent standards and patterns when designing and iterating upon APIs. However, I am also seeing more investment in API governance that is more about operational level API governance, than just focused on the design of APIs. API design governance focuses on the surface area of your APIs using OpenAPI and other API specifications. Governance at this level is critical, but it is also important to be governing across multiple versions of an API, looking not just at each API in isolation, but also in context of previous versions, otherwise you will always possess a limited view of what is happening. It is natural for us always to be looking to the future, but it is also important that we are building a future that doesn’t ignore the past, because not all of our consumers will be moving forward at the same pace, or with the same context. Being able to see breaking changes across multiple versions of our API is an important place to begin with this type of operational level API governance, but then we should be able to go even further, understanding the impact of change across our consumers. Like design governance, we are going to have to automate the governance of change across...[Read More]
Why I Pay Attention to APIs
17 Jan 2022
It is that time again. Time to remind myself, and anyone who reads this, why it is that I pay attention to APIs. There are many people who simply hear my title and make all kinds of assumptions about who I am and what I do, without ever spending the time to get to know me. Most people I grew up with know I do something with technology, but have zero awareness of what I actually do day-to-day. Even beyond what other people think about what I do with APIs, I find myself perpetually slipping into a kind of comfortable numb with my job and wider work, regularly forgetting why I do APIs, requiring regular re-affirmation of why the hell I am here in the first place. First, I started doing API Evangelist in July of 2010 because I saw the importance of not just the technology of APIs, but also the business of APIs. I understood the technology behind SOA and the emerging RESTful wave of APIs, but I was seeing more business dimensions I needed to understand. How APIs were being used to define entirely new business models like the cloud, but also APIs as a product like Twilio and Stripe. As I begun to understand more about how APIs were being wielded in service of business, I also begun to better see a third dimension, which I began to call the “politics of APIs” around 2013, after spending more time in Washington DC. I created this diagram almost ten years ago, but it still applies to how APIs are being manipulated to control markets, elections, and so much more of our everyday life. Despite popular belief, I am not pro API. The cat is out of the bag, and there is no turning back, and I see APIs as the primary tool in our toolbox when it comes to making sense of this digital world that is unfolding. Despite my daily evangelism...[Read More]
You Are API-First
14 Jan 2022
I am really struggling on a number of calls lately with people at companies who are doing really interesting things with APIs, having fully committed themselves to prioritizing APIs across the organization, but are reluctant to say they are API-first publicly as part of some storytelling. Out of some insecurity around the shortcomings that exist across operations, and an inability to convince every team to perfectly follow some perceived API-first process, people are nervous about agreeing to declare we are API-first. Despite having invested years into prioritizing APIs across operations, and having become more proficient in delivering APIs across a known API lifecycle. I struggle with reconciling people’s desire to be API-first with their reluctance to declare they are API-first, and I’d like to understand this better, then refine how I talk about API-first to help address more in the future. First, what is API-first. I am very opinionated here. API-first is simply the prioritization of producing and consuming APIs over the application of digital resources and capabilities. API design first is API-first. API code first is API-first. API-first is not every single team and API within your organization following some spiritual path of API perfection and enlightenment. Being API-first means that as an organization you have made the commitment to prioritize APIs over the application of digital resources and capabilities. It means you are committed to doing the work to invest in your API strategy, follow and known API lifecycle, and bring the necessary reliability, observability, and governance to your operations. API-first is a journey, and not a destination. If you view API-first as some sort of complete state of API utopia, you will never get there. If you are committed to prioritizing APIs, and doing the work as an organization, then you are API-first. I had three separate conversations around this yesterday, beginning with a live stream on the subject, where there was reluctance around declaring that Postman was API-first, and ending with...[Read More]
The OpenAPI Community
22 Nov 2021
I am taking a moment to recalibrate my chess board for the OpenAPI community, and there is no better way for me to accomplish this than to write a story here on the blog. I have several folks I am working with to help move the OAS conversation forward as part of official OAI efforts, but also as part of Postman Open Technologies, and having a map of the landscape loaded up into my head and easily referenced as part of conversations helps me move things forward. As of November 22nd, 2021, here are all the moving parts of the OpenAPI discussion for me, organized as a simple narrative focused on moving the community forward: Learning I do not want to assume everyone knows what OpenAPI is, and here are the links you should tune into if you are looking to learn more about this important API specification: Website - The OpenAPI website. Documentation - The OpenAPI documentation. Getting Started - Where to get started. Blog - The OpenAPI blog. Twitter - The OpenAPI Twitter account. These are the basics of where you can learn about what OpenAPI is, and how you can put it to work, then stay in tune with the community via stories on the blog and conversations on Twitter. Contribute If you are wanting to do more than just learn what is happening I recommend using these resources to quickly understand what is happening and get more involved at the technical level. Specification - The repo for managing the spec. Github Issues - The issues driving the spec road map. Discussions - The Github discussions for the spec. You can find everything you need to keep up speed on what is happening with the spec from a technical point of view using these links, and contribute to the conversation and overall road map. Meetings There are two core meeting that you can tune into to get a handle on the technical...[Read More]
Design-First, Prototype-First, or Code-First APIs
20 Nov 2021
I strongly believe in a design-first approach to delivering new APIs, and future iterations of existing APIs. Having an OpenAPI artifact to guide discussions, services, and tooling saves you time, money, and frustration across the API lifecycle. This isn’t opinion, this is fact. However, I also have grown to be very pragmatic in how I approach the API lifecycle, and fully grasp that adopting API-first effectively across teams isn’t something that all enterprise organizations will have the time, skills, and other resources to make happen. Resulting in me supporting design-first, prototype-first, and code-first approaches to delivering APIs. I will keep investing in stories and demonstrations of what, why, and how API design-first makes sense because these three realities I see across the landscape keep me from getting too dogmatic on this subject. Design-First - Using an OpenAPI to document, mock, test, and iterate upon a new or existing API make sense if you have the time and skills, but when you don’t it is something that can become half-baked and causing problems throughout the API lifecycle, so make sure you are properly investing in API-first, and not just jumping on the bandwagon. Prototype-First - This one actually surprised me, but when I saw folks prototyping APIs using a Postman collection, which provides the ability to mock and document your API without an OpenAPI, but then generate an OpenAPI once you get to an agreed upon state, I began making sure prototype is part of the equation when it comes to delivering APIs. Code-First - Coding is what most developers get, and there are plenty of ways to use annotations and proxies to still ensure there is an OpenAPI for code-first projects. Using code-first approaches to rapidly prototyping while still adopting many of the iterative approaches to moving an API forward can be just as effective as many design-first approaches. It would be nice if everyone could just stop what they are doing and learn OpenAPI...[Read More]
Being Transparent By Default and Over Communicating When Doing API Specifications
20 Nov 2021
I forget what a great vehicle API Evangelist for sub-tweeting conversations that I see occurring across the API universe. I made a career out of doing this for the last decade, taking a moment to anonymize and generalize conversations and realities I witness across the space, writing up here as a story, and using them to help educate and bring awareness to the API universe. One that I am finding myself doing more storytelling about is about the transparency and communication necessary when building API specifications. I wrote about this last week on the Postman blog showcasing the radical transparency of the AsyncAPI community, and it is something I want to continue highlighting because it is very difficult to get and keep people’s attention in this digital world. You have to be transparent and open by default when you are building API specifications. I don’t say this just for some hand wavy ethical stance, but it is critical to ensure your community is informed and aware, and keep people from gumming up the works with their lack of understanding and obstruction to forward motion. While doing the hard work of moving any open source specification or tool forward you find yourself inundated with drive-by feedback from folks, and if you aren't extremely clear about how folks should be tuning into the conversation, and make every action public across multiple channels, this feedback will be even more uninformed than it has to be. People just don’t have time in their busy days, and most people aren’t equipped to see the work that is already occurring within an open source community. So when they do come across a single issue, meeting, or other relevant conversation, the likelihood that their feedback will be uninformed and not in alignment with the community is pretty high. People, especially men excel at stepping into a conversation wildly unprepared, uninformed, and oblivious to the hard work volunteers and the community are already...[Read More]
Needing Inspiration to Care About APIs?
18 Nov 2021
I always enjoy when I have the opportunity to light up someones imagination when it comes to APIs. I have had a couple of conversations with folks recently who had never heard about APIs until they talked with me, and then after fifteen minutes of chatting had developed a curiosity around the fascinating acronym. I have been captivated by APIs for almost twenty years, with a decade long obsession around everything API. APIs keep my attention because they come in so many shapes and sizes and are something that is touching almost every aspect of our personal and professional worlds. I have to admit though, there are times where I get sick of APIs, but inevitably I come across some new use of APIs that renews my passion and interest. I get the reality that not everyone cares ab out APIs at the level I do, but I am always happy to try and convince people that they should care, even if they aren’t a developer. One way I am able to capture people’s attention when it comes to APIs is by having a treasure chest of stories about how APIs can make a difference in areas that people care about. One recent area of inspiration I stumbled into involves a story I was reading about Fighting food wise, one apple at a time in the Washington Post, which is summarizes as follows: Katherine Sizov is only two years out of college, but her high-tech sensors — which monitor ethylene, a gas key to the ripening of fruits and vegetables — are keeping watch over 15 percent of U.S. apples. Which after reading I typed “Strella Biotechnology”, the name of her company plus “API” into Google. This is something I do multiple times a day as I am reading an interesting article. It is how I perpetually stumble into interesting areas of API development and meet people doing interesting things with APIs. Strella Biotechnology doesn’t...[Read More]
