Questioning how I see the technology, business, and politics of APIs is the foundation of API Evangelist. I’ve changed my opinions on a lot of things over the years, as my awareness expands on different topics. Right now I am questioning how I see and approach API governance. In an attempt to try and apply what we’ve built at Naftiko to the problem of API governance, I find myself question a lot of what I’ve been writing about when it comes to API governance. IDK, maybe I am over thinking it. Let’s see. Let’s start with, what is API governance? Well, in is current form, API governance is about coming up with a set of design rules (Spectral / Vacuum), which are used to “lint” or “validate” the design of your API, the paths you use, the summary, description, and identifier for you operations, and the schema you pass back and forth between APIs and their applications. This “design of your API” is usually expressed as an OpenAPI or AsyncAPI, which can be “listed” or “validated” when designing in your IDE or other editor, at the CI/CD pipeline when an API being deployed at any stage, as well as at the gateway when be used by any application. API governance generally means you are going to establish these rules, publish them to a central style guide, and the design of any new APIs will be “governed” at design, build, or runtime. The theory (and practice) is that API governance will change the behavior of teams, producing standardized APIs across teams and domains. That we will be able to agree on a common set of “rules” governing a standardized set of design patterns, and effectively “govern” all of these across different domains and teams who are using different tools and process. This belief system often leaves me wondering if what we are setting out to do is even possible, and if we could do it today, would it solve all of the problems we think it would? I believe the path forward involves everyone who is producing APIs at enterprise get the training they need to deliver many different types of APIs that are suited for different purposes, but it is something I’ve been pushing for now since 2010, and haven’t achieved so I need to find other ways. OK, so with governance. We want to ensure that all APIs have standard design patterns, such as path names and parameters. Clearly there are plenty of other patterns, but for simplicity let’s focus on just two of the most API governance rules and design patterns out there, and we’ll let our imagination apply to all the other patterns. For this story I’ve generated Naftiko Capability that consumes three different APIs from three different teams who each have their own design patterns, to which I expose as consistent paths and parameters, transforming what exists into what I envision in an governed API world. So, why haven’t we just done this before? I can…