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.
You can feel the business world easing into the embrace of the holiday season, as well as out of the delusional grip of the AI hype machine as the heavyweight gamblers in the casino begin to move some of their chips back to the Bitcoin slots on the roulette wheel. While the new administration will be kind to AI, it is going to even kinder to Bitcoin, and as an API ambulance chaser I’ll be doing more profiling of who the API hustlers are in this space.
Even before you begin enforcing API governance, there are so many lessons to be learned from profiling the enterprise API landscape, as well as within a particular industry. AI, Bitcoin, social networking, and federal government in the United States are all areas I am working to profile in this moment. While AI and Bitcoin aren’t my jams, in times of trouble I tend to lean towards developing a better understanding of how the machine works—leading me to learn more about areas being leveraged, exploited, and disrupted.
Stories
So much is broken right now. I implemented a more advanced search for API Evangelist this week, just so I could find my own stories. I usually rely on Google for this, but it just doesn’t surface what I know is there anymore. Search isn’t the only thing broken right now, and social is the other essential part of the bill of goods sold to us with Web 2.0 that is completely broken in this moment.
To help me understand the role that APIs play in fixing or further breaking social networking I dove into the Bluesky, Mastodon, and Threads APIs, while also reading about how decentralized Bluesky really is, but also Anil Dash’s important story on how we can’t turn over an important tool in our toolbox, the newsletter, to the facsists. I am not convinced we can fix the socials, but do believe that decentralized and federated approaches to tech is how we’ll continue to muck up the machine from centralizing the last bit of goodness that exists online today.
Guidance
My work on API guidance this week was primarily focused on adding a search layer to the guidance I’ve already produced, right alongside the new search for my blog. Making my existing content available to me, but also to help guide my readers forward was the priority for me this week, so I didn’t produce any new content to add into the mix. There is so much guidance available via the API Evangelist domain, but if nobody can find it—it don’t mean a thing.
As I was profiling the Fast Healthcare Interoperability Resources (FHIR) to produce some hands-on guidance for healthcare integrations I realized just how much work is still needed to make the standard usable in the real world. The FHIR specification needs some serious workshopping using the OpenAPI Arazzo Workflows before we will be able to onboard mass numbers of developer to do the work tht is needed. This type of work often isn’t seen by people who craft technical specifications, and they prefer to assume everything you need is available the final version of the spec.
Services
Talking to customers and would-be customers this week I am reminded again about how many people just do not care about APIs, and will only see the outcomes they provide. It makes me realize just how much we believe our own stories and hype in the tech space, and that we will continue to stumble as we fail to align our beliefs with the realities on the ground within enterprise organizations.
As I continue to develop my services for helping enterprise manage JSON Schema via Git repositories, I developed the first layer of fundamental Spectral rules for linting your JSON Schema artifacts. My goal with this work is to ensure that each schema has an id, the latest draft of JSON Schema, as well as the metadata needed to discover and understand what each schema is for. Not having your schema house in order is the biggest area of friction when it comes to implementing API governance at scale.
Discovery
When you are profiling thousands of APIs you begin to realize that there are some serious challenges with automating the profiling of these APIs, and it isn’t something that will be easily solved (even with AI). Simple things like articualating that an API is an open-source API vs a cloud API in a machine-readable way become monumental tasks that we’ll need much more standardization around.
My work continues to convince business leadership of the impression that their developer portal, or lack of a developer portal leaves about the ways things work (or don’t) within their enterprise. I am also continuing to automate the discovery of API evidence across the enterprise to help contribute to a more fuller picture of the API sprawl and chaos that exist across the average enterprise organization.
Overlapping with my work on API policies, rules, and API discovery, I produced an APIs.json, OpenAPI, and Collections for the Open Policy Agent (OPA) API. I am looking to leverage the existing approaches enterprises are taking to govern their infrastructure across operations—injecting and widening API governance policies and rules will continue to be an important way that I build API governance inroads into the enterprise.
Commons
On the tail of publishing policies and experiences schema the last two week, I contributed a new rules schema to the API Commons this week. I find the Spectral rules schema to be lacking in the metadata and other properties I am needing to align API governance with the wider business side of operations. I need descriptions, tags, and other rich metadata to properly apply and evolve Spectral rules across operations, so I have added a wrapper schema to my Spectral rules, which will let me take it new places.
The API Commons rules schema allows me to add Vacuum API governance rules to the stack, going beyond Spectral rules when it comes to API governance. It also allows me to expand to Open Policy Agent (OPA) and widen governance across other areas of API operations. Spectral has a very narrow technical focus on the governance of the design of HTTP APIs, which others are trying to expand to AsyncAPI and GraphQL. I am confident Spectral can go wider, but as with API specifications, we are going to need multiple rules engines to expand governance across the enterprise.
Reading
I am reading the Restless Clock, A History of the Centuries-Long Argument over What Makes Living Things Tick by Jessica Riskin. It is a great book for revealing that the desires which exist around artificial intelligence are nothing new, but are also relevant to my earlier state regarding how search is broken. As I am reading about hydraulics and automata between 1300 and 1700, I find myself googling hydraulics, a time period that is not present in a single blog post at the top of search results—there is only a lot of hand waving about hydraulics used by Egyptians and one Arabic person in 1200, but nothing until hydraulic fluids are discovered in 1700s. It is almost everyone is just copying everyone and nobody is going to the library.
Beyond printed words, Docusign Expands Its Developer Community With New Platform, and Foursquare Open Source Places, providing a new foundational dataset for the geospatial community.— who knew Foursquare was still doing the good work? Our World in Data also released a new Chart Data API, but with two steps forward we always take a step back as Strava did this week by stopping sharing fitness data with other apps.
While still focused on just HTTP APIs, I am accumulating work like AWS introducing CloudFormat Hooks that are invoked via AWS Control API—preparing for a deeper dive into webhooks. I am also keeping a side eye on the real world AI use cases enabled with APIs like Salesforce is doing with their Models API that creates SVG images dynamic, and what the motivations behind Stripe releasing an AI Agent Toolkit might be. I’d say the only news that really interests me from the AI world this week was why everyone imitates the OpenAI API—this emulation and reuse is a compelling argument for API standardization and reuse.
API Evangelist 2025
There is a ton of amazing work happening on the new platform for API Evangelist, except the web interface is only available locally right now. This is leaving me struggling with sharing relevant links and images supporting what I mean when I talk about the future of how I see API governance, and the alignment with business I am investing in within this moment. I will push harder during in the next couple weeks to just hit publish and deal with it all being so very beta, just so I can demonstrate more of what I mean.
Right now my audience and customers are just getting very abstract looks at my API governance work, or very modular YAML bits which are driving things. I get that it is hard for folks to piece things together without a visual interface. When I first began this work after leaving Bloomberg I anticipated that my new visual interface would be a separate dashboard from API Evangelist, but now I am pretty convinced that my dashboard will replace the current API Evangelist website. I am looking to turn my API workbench into my website, because this is really what API Evangelist has always been throughout the years.
You take care of those humans you love this holiday season—make sure you get offline to spend time with them.
