Weekly API Governance (Guidance)
My name is Kin Lane—I am that API Evangelist guy who has been paying attention to the technology, business, policies, and people of APIs since 2010.
Git was the central actor in my API Evangelist circus this week. While API Evangelist runs almost entirely on GitHub, my work using the open-source API client Bruno this week, as well as with API-Fiddle, OpenAPI Doctor, and APIMATIC, has me thinking about the role Git plays in the technical and business dimensions of our API operations.
Git is the intersection of everything across API operations. An obsessive focus on Git + specs is how I intend to help API producers govern (guide) their teams who are crafting APIs, while avoiding as much of the enterprise politics attached to existing services and tooling. I am actively studying the approach of Bruno, and the reality that Git is how you “Run” APIs in Bruno. I am also talking to SourceMeta and other partners about how we can sustainably make money on top of managing specs with Git using a mix of open-source and enterprise services.
This week was a series of overlapping API plays with Git as the central actor, which I think will be a continued theme in my work—right along with APIs.json, OpenAPI, JSON Schema, and Spectral on the specification side of the equation. I can’t articulate enough the importance of Git + specs when it comes to how we are going to keep the API conversation moving forward with as little baggage as possible—so I will just have to keep demonstrating what is possible.
Stories
There are a lot of APIs out there. I am fascinated by the number of, scope of, and complexity of the API landscape today. After getting intimate with thousands of OpenAPIs for leading API producers I can confidently say that we are often times loading too much into our APIs, and we should be thinking more about how we can bundle and unbundle across our API operations.
APIs are notoriously hard to see while also being extremely ubiquitous, leaving me perpetually searching for new ways to make APIs visible through storytelling, while also studying innovation at the intersection of OpenAPI editor and governance rules out of OpenAPI Doctor from Princess Beef Heavy Industries (you heard me correctly).
While everyone else is investing in governance through a technical lens, I believe that investing in the future of a visual OpenAPI editor, but also introducing a more snackable, shareable, forkable, and embeddable visual OpenAPI editor is what we need to get business stakeholders more involved. With that said, we also need continued innovation like what APIMATIC is doing with editing and governing OpenAPI in the IDE.
Guidance
My world operates on Git. Specifically GitHub. The same is true for most companies, organizations, institutions, and government agencies today. I am laying down my guidance for enterprise organizations to build a basic foundation using a simple Git repository to manage the schema you use across all of your APIs—starting small and not boiling the ocean when it comes to using Git as a schema registry.
Git is a foundational building block of enterprise operations, and the cornerstone of business model for the open-source Bruno API client I have swapped out as part of my operations. As I’ve expressed before, Git should be the default operating mode of anyone selling services or building tools for the API space. I can’t think of a better technical and business blueprint for the services and tooling we adopt than Bruno, which is why you’ll hear me demonstrating my approach using Bruno from here forward.
Services
Git isn’t just core to Bruno’s business model, but also my own. I worked to highlight my approach to managing both JSON Schema, as well as OpenAPI via a single or separate GitHub repositories this week. These are two foundational services I am using to profile thousands of public APIs for APIs.io, as well as internal, 1st-party, or 3rd-party APIs for my API Evangelist customers.
How I can make money, as well as how the service and tooling providers I use and partner with can make money was front and center for me this week as I explored how to make money with an API hustle. I have a lot of strong feelings of what is acceptable and not acceptable, and will be continue to explore the intersection of how to sustainably fund an open-source distributed traveling API circus—step right up!!
Discovery
You can see an example of how I am using GitHub repositories combined with an APIs.json index of OpenAPI and Bruno collection and environment to profile and make forkable the HTTPStat API, which can be used in testing, training, and other compelling API productions.
Each API I profile for APIs.io gets this same treatment via my new API Evangelist dashboard. I can profile a simple but useful API like this in about 5 minutes, immediately making it more accessible and usable by someone looking to put to work. I have already done this across thousands of APIs and will continue to do until I’ve discovered every last API on earth (so forever).
The API Commons
My contribution to the API Commons this week was the publishing of an experience schema which I use to organize API governance policies and rules. Experiences help me map very technical details of operations to the very real human details of operations, with an emphasis on making the lives of developers who produce or consume APIs easier through API governance (guidance).
API experiences help align the very technical rules and the very business policies with the actual humans who are producing and consuming APIs. Experiences help distill Spectral rules into things that matter in API documentation, sandboxes, software development kits, change logs, road maps, and other ways the teams producing and consuming APIs experience their day.
Reading
Not a whole lot caught my attention this week online, but I can’t recommend highly enough the book by Oliver Burkeman called Four Thousand Weeks - Time Management for Mere Mortals. It is transformative. The book gets at the anxiety we are all increasingly experiencing as we spend more of our physical lives in a digital world.
Back to the digital world...Google debuted an OpenAI-compatible API for Gemini—which is an interesting competitive move using an API. Snowflake went all API-first with their REST & Paython Control Plane API, and security continues to be top of mind over at GitHub with the release of their push protection bypass request details being included in the REST API, webhooks, and audit logs for secret scanning alerts.
After blending my physical and digital reading in this weeks newsletter, I will work to keep this the balance moving forward. I am always reading one book and listening to another book in any given week. This will help me further slow down and thinking about what I took in this week across the reading spectrum—we’ll see which produces the most interesting stories.
Demonstrating
Storytelling in the API space is my favorite way to spend my time. But, demonstrating how you can do something I talk about in my stories is exponentially more valuable because your story can be forked and applied in anyone’s world. Story + Repo + APIs.json + OpenAPI + Bruno == demonstrating API value. This is what I love about the world of APIs.
Similar to how I worked this week to swap out Postman with Bruno because of OpenAPI and collections, I am confident when the time comes I can swap out GitHub because of Git. I am going to add Git to the API Commons in coming weeks alongside APIs.json, OpenAPI, and the other common building blocks of APIs. Moving forward I feel like things are going to continue to be “back to basics” when it comes to the API protocols and patterns I am demonstrating and telling stories around.
