Weekly API Governance (Guidance)
My name is Kin Lane—I am the API Evangelist who has been paying attention to the technology, business, policies, and people of APIs since 2010.
This is the first edition for version 2.0 of my API Evangelist newsletter. I am a fan of email newsletters, and I wanted to rekindle one for my domain, but this round I am looking to provide more of a weekly narrative across my work, rather than just an RSS list of stories I published for the week. I understand there is no way that anyone can read everything I publish throughout the week and it is near impossible to be able to follow along with all of the projects I have cooking. So, if you read nothing else from me, I hope you read this newsletter and let it provide you with a summary of everything that happened during the previous week, and a better understanding of where my head is at—-I leave it to you to extract the nuggets of information that are of interest to you.
I am hyper focused right now on developing the base set of API governance policies and rules for my new line of API Evangelist services, so I am evaluating where Spectral fits in with Redocly’s and Vacuum’s approach to API governance linting rules. I am refining my own approach to using positive and negative rules, as well as grouping my rules in more relevant ways, while laying out where the rules work should be happening, and why that Spectral rule may not be as effective in governing your APIs as you’d like. I helped review the new OpenAPI cheat sheet from Bump, which I will be writing more about along with publishing a base set of Spectral rules that reflect the different areas Bump focused on with their cheat sheet.
Beyond API governance rules, I am increasing my focus on the business of APIs, using my API policies to align product and engineering, and evolving how I can help influence your API strategy from the outside in by writing about your competition. I had a conversation with Dale McCrory about the view of the API lifecycle from the perspective of a product manager, and I attempted to highlight how immature the world of APIs is by comparing it to the energy and electricity industry. I am really interested in understanding what tooling we should be investing in to get product managers more involved in the API lifecycle, and develop a better understanding of how business decisions introduce breaking changes into our operations. I also thought that Bruno Pedro’s API Changelog newsletter this week on why everyone imitates the OpenAI API reflects the business reasons for why and how we should invest in APIs, by emulating the successful API patterns we know and our consumers will know as well—then who knows, maybe you will be emulated by others.
I also sat down with my good friend Robert Buchanan from Procter & Gamble to get his hot takes on the API space (which I always enjoy), as well as had a conversation with Jamie Tanner from Elastic about why you should start your API at version 0.1.0, because you haven’t done the work to call it 1.0.0 yet. Despite not traveling I got a shout-out at API Days for my declaration that I was staying 100% focused on HTTP APIs, with what appeared to be an existential dig for the event-driven API realm-—I love it. I always enjoy when I am in people’s slide decks, even when it is for controversial reasons, as it saves me the flight and conference fee of having to attend. I won’t be traveling at all in the near future, and the only time folks will catch me at events is when they are in New York City. I cherish the time I spent at events in the past and owe much of my career to it, but I am enjoying staying home with my wife Audrey and my dog Poppy much more these days and immersing myself in my API Evangelist and APIs.io work.
That concludes what I focused on this week from an outbound perspective. Most of my work this week was behind the scenes on my strategy, platform, policies, rules, and guidance for APIs.io, which is the showcase for my new API Evangelist services. You can take a sneak peek at the README for the review I did of the APIs.io Search API. Not all the links work, and there is still more data I need to publish. However, it provides a sneak peek at my new approach to conducting an API review, which acts more as an API guide than an API review, helping showcase all the work that has already been done, as well as the work that is required to move to the next step, while providing common platform resources and Just-in-Time API Guidance to keep each API moving forward in a consistent way. While I am using the APIs.io Search API as the high water mark for my API governance services, once I apply it to some of the other APIs.io APIs it will become much more clear how this acts as API guidance, and not just as an API governance review. Once I get this work done I will move back to profiling new APIs from across many different industries as part of my APIs.io work, and conduct a review of my own API Evangelist APIs. On top of all this work I will be keeping the usual drumbeat of API storytelling going until I get back to the velocity I had previously with API Evangelist.
I am really thankful that y’all are tuning in!
