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.
As we get closer to the election in the United States I am working hard to stay off social media and the websites for the news media outlets. It is a good time to stay focused on my work on APIs and keep my anxiety levels low. I am confident that this country will reject hate and we will get through this moment. I find comfort in voting and will burn up some of my anxiety profiling federal government APIs—something I’ve done since 2013 to help feel like I giving back.
The holidays have long been a time for hunkering down and getting big projects done—this season will be no different, and I already feel my momentum picking up. My storytelling volume is getting back to levels that make me happy, and my work on policies, rules, and other artifacts are paying off in support my new API Evangelist dashboard which I will be using to manage APIs.io, API Evangelist, and mapping my customers API landscape, lifecycle, and governance.
Stories
There was an APIdays Insider Reception in NYC this week. I had accepted the invitation, then was asked to host as Baptiste Parravicini had gotten Covid at API Days in Australia. I prepared a narrative to guide my talk, but I ended up holding court with several of the major banks, Walmart, and Maryland Department of Health—the experience was a refreshing reminder of the importance of face to face events.
While iterating on the machine-readable API plans schema for APIs.io, I spent some time thinking about how to communicate that an API is free to use in a machine readable way. I was distracted from this work mid-way through the week with the the Consumer Finance Protection Bureau announcement around finalizing rule 1033, and was forced to share my initial thoughts on 1033, FDX, and the lack of API nutrients. As the week closed I begin working on an API Commons and APIs.json project using the new Arazzo workflow specification, and published a story about the JSON Schema for the spec.
Conversations
Raymond Camden, Developer Advocate at Adobe came by for a conversation about how he is using Google Gemini AI to augment his prolific storytelling — I think he is one of a handful of people who have been blogging longer than I have, with a similar appetite for publishing.
Later on in the week I was joined by Luke Seelenbinder, Founder & CEO of Stadia Maps to learn more about why they are taking on Google Maps, and understand Luke’s views on being product-led, and what APIs as a product means. I find it refreshing to talk with small business owners like Luke who are doing one thing well and doing the hard work to understand what markets actually need and can bare—rather than just steamrolling over them like the tech giants do.
Guidance
The API Evangelist Platform continues to come into focus, and as my user interface for managing APIs.json business contracts and OpenAPI technical contract becomes more functional I am realizing a vision I have had for some time regarding how to provide Just-in-Time API guidance as a kiosk in the right hand menu.
This Just-in-Time API Guidance kiosk is designed with the information kiosks on the NYC MTA subway platform in mind. I appreciate how these kiosks do not drown you details about the overall system and only provide you with a handful of things you need to know to get where you want to be.
Services
To support my Just-in-Time API Guidance kiosk I needed to map a handful of business experiences to technical rules using API policies—this is how will be aligning the business and technical sides of the services that I offer to my customers. I am continuing to work through my base policies, rules and guidance for my customers—this time it is governing the latest versions of the specifications we use across API operations.
Every enterprise I have worked with in the past has a mix of Swagger 2.0 and OpenAPI 3.x specifications spread across operations, and are rarely ever using the latest version of JSON Schema to validate things. Managing the versioning and change across our API operation is one of the most important things we can do to stabilize business operations.
Discovery
After getting distracted by the CFPB 1033 ruling and diving into into the FDX standards they propose, I found myself profiling Mastercard’s FDX API, which I think provides an important blueprint for others to follow, or maybe just utilize Mastercard’s sophisticated suite of 1033 compliant services.
As I said in my FDX, 1033, and API nutrients post, I think that CFPB and FDX could do a lot more to open up and invest in community around this public standard that is meant to drive more interoperability. In my experience, many people overlook the human aspects of these standards, and just assume the technical details of APIs will magically make these things work—they will learn the hard way.
The API Commons
The API plans schema I am using for APIs.io was given a JSON Schema this week, resulting in me contributing an example and the JSON Schema to the API Commons. Right after authentication, plans, pricing, and rate limits I feel should be the next place we invest in when it comes to making the human elements of our API operations more machine-readable to support AI and automation.
There is a lot more work to be done on the API Plans schema, but it provides a good starting point. I will continue to flesh out the schema based upon leading API providers that I profile as part of my APIs.io work. The more existing APIs that I describe using this API plans schema, the stronger it will become, helping other API providers get more structured in how they publish and communicate around their API plans (you have one, right?).
Reading
The prediction that according to Fortune Business Insights, “the global API management market size was valued at USD 4.28 billion in 2023 and is projected to grow from USD 5.42 billion in 2024 to USD 34.17 billion by 2032” is pretty compelling. While I am skeptical of these types of predictions, I am confident that world of APIs will keep growing in significant ways.
I got all worked up about a story on why duplicating environments for microservices backfires, learned a lot about why charset matters from Ecoding Differentials, and was drawn in by Ngrok’s approach to dropping in gateway policies to manipulate headers—all of which I will be including in my guidance and driving more storytelling.
On the heels of the Arazzo workflows specification from the OpenAPI Initiative (OAI), version 1.0.0 of the OpenAPI Overlay Specification was released this week. This is good to see. It was something that has been in the works for some time now, and will have a huge impact on important areas like change management, localization of APIs, and other ways our APIs are being experienced by different consumers.
Trust in the Process
As the week closes I regularly find myself feeling like I haven’t completed enough work. As I work my way through crafting this newsletter on Sunday evenings I am always pleasantly reminded of just how hard I have worked, and the definitive direction I find myself headed in when it comes to crafting my API governance services. I am learning to be more forgiving and give myself grace each week as I head uptown on Saturday mornings to get bagels for the week.
It can be hard to understand all the moving parts of my API governance work in motion, but this newsletter reminds me that I have a good framework in place, and that I just need to trust in the process. While I don’t think the work will ever completely be done, I have a well thought out process in place for evolving the rules I use to define my baseline governance for HTTP APIs and aligning operations with real-world business outcomes using policies, strategy, and experience schema. I just need to keep beating the drum each week until the new year (and beyond).
I really appreciate you all subscribing and tuning into my work.
