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.
I am still taking things slow after my mother passed last week. I am only responding to existing work and new requests from would-be clients. However, I think that I still have enough nutrients to fill out this weeks newsletter and offer a little API guidance to my readers.
One thing I find comforting during times where I feel emotionally thin is coding (it doesn’t take much humaning). So this week I began developing the APIs behind API Evangelist, refactoring my approach (once again) to how I deliver simple HTTP APIs, working to reduce the complexity and dependencies I have created across the APIs that I use to power API Evangelist.
Stories
I was thinking a lot about API reviews this week. I am working to better communicate my own approach to reviewing APIs to my would-be customers, but also thinking more constructively about what an API review should and shouldn’t be. My story on what an API review should be is guiding my API design work this week, as I work to keep governance more about guidance and not being an overwhelming attack on what you don’t know about APIs, and drowning you in technological ideology.
My review of the APIs.io Search API has shaped the design of my API Evangelist APIs, and ultimately my development of an API review interface, because I realize that my current approach to publishing a review is just information overload via a GitHub README.
Conversations
I sat down with my friend Sue Smith from Fastly to talk about API education, training, and guidance. Sue gets developer advocacy and education, and she is passionate about developer experience. Sue’s track record in delivering education for tech companies is long, but it is the fire in her belly due to her life before tech that I find most engaging and able to align with.
Guidance
What I learned working with Sue at Postman as well as providing the API guidance teams needed while at Bloomberg has shaped my views on how API education needs to be delivered as part of wider API governance (guidance)—this is something I’ve been talking about in the videos I produce to evolve my approach and polish my guidance.
Services
I published one of my customer pitches from this last week, emphasizing the follow core set of API governance services for enterprise API producers:
API Inventory - Inventorying existing APIs using open-source API specifications.
Source of Truth - Publishing API inventory to Git repositories for automation.
Governance Rules - Produce rules to automate governance across all APIs.
Governance Policies - Produce policies to align governance with product teams.
API Reviews - Review existing and new APIs using defined policies and rules.
Developer Experience - Provide the API artifacts that generate docs, mocks, and SDKs.
These bullets are proving to be the base stack of services I use to deliver API governance for my customers, helping enterprises get a handle on the HTTP API sprawl that has emerged across their enterprises.
Discovery
As part of my renewed work on API Evangelist and APIs.io I have fired back up the Postman platform and paying for an enterprise license. Like other old platforms I turn back on I have to contend with the results of previous work there—which may have been simmering for years. Leaving me plotting on what I am going to do with all of the traffic to the Postman API workspaces and collection that I have published.
I will be linking up this work with my APIs.io profiling, making sure existing API workspaces are accounted for and publishing new workspaces for any APIs that I profile and include in the API search index.
The API Commons
One piece of my work on API Evangelist APIs that I am happy to showcase from this week was the APIs.json, OpenAPI, and JSON Schema I produced for the JSON:API—resulting in quite a mouthful of API specification fruit salad. I like using the JSON:API success response object as part of any API I develop, so I went ahead and produced a base set of artifacts that I published to the API Commons for anyone to fork and use in their work.
Thankful
I am thankful for my API Evangelist work in this moment. I enjoy the scope of this work, and thankful I have it lean on as I mourn the passing of my mother. Everything in this newsletter reflects my expertise, but also my passion—I enjoy thinking within this space very much.
I am going to be immersed in the development of API Evangelist APIs for the next couple of weeks, but along the way I will be continuing to publish reviews of APIs.io and API Evangelist APIs that are in motion. This work reflects the collision of the API review process for API Evangelist and the API profiling process for APIs.io—which are really one and the same, just conducted for different purposes.
I will make sure I am producing as many artifacts as I can to share via API Commons, as well as many stories for API Evangelist as I have the mental bandwidth to write—thank you for tuning in!!
