The API landscape within any enterprise organization is ever changing and evolving, and with APIs being such an abstract and often undocumented aspects of organization work, it can be very difficult to “see” APIs, let alone the forward motion and change of our API infrastructure. As much as we’d love for our teams to properly document all APIs used to power web, mobile, device, and network APIs we depend upon and iterate upon each day, the reality is that APIs regularly possess paths, parameters, schema, and other properties that aren’t always well documented and made “visible” as part of the API development process. This ever expanding shadow landscape of our enterprise API operations is the where the latest waves of startups like Akita Software> are making their mark on the API lifecycle.
Akita Software describes itself as an API observability service that helps organizations build API behavior models that expose the reality that exists across our existing API factory floor, then allow teams to produce diffs, merge, and extend definitions of our APIs. I love the type of innovation that Akita Software represents in the API space because they don’t directly see API specifications like OpenAPI in the same light as the rest of us do, they see what exists in the cracks and shadows of the OpenAPIs we produce as part of our regular API operations. Akita Software allows you to watch API traffic from a server, a browser, and via a proxy, and produce OpenAPI maps of the API landscape behind our applications and integrations, producing a more honest view of the ever changing, evolving, and potentially breaking waves of API change under the hood of our companies, organizations, institutions, and government agencies.
While the end goal in using a service like Akita Software might be about delivering more up to date documentation, or ensuring the coverage of your API testing is more complete, my belief in why their approach matters is because it allows us to see API change. Just pause for a moment and think about how you “see” an API. Is it documentation? Is it the end application or integration? Then think about how you see the change that occurs across the evolution of existing APIs and the introduction of new APIs. It isn’t easy. This is why innovation at this front line of our API operations is so important. As many enterprise organizations invest in API observability in the sense that they should be testing and monitoring API instances, those who are further along in their API journey will soon realize that this effort is limited by what is known of your the API landscape. And that API observability involves perpetually discovering the reality of what APIs are in use, diff’ing that against what is known, and increasing the coverage of API observability efforts.
I have conversations with Jean Yang of Akita Software in my archives that I haven’t been able to publish, and I am just now working my way back through to produce some long overdue stories here about the importance of API specifications derived from these conversations. Jean has a view of the landscape that reflects a shadow Venn diagram of what is missing when we talk about API specifications, but also how they contribute to API discovery, documentation, testing, security, and much more. Akita Software’s approach to API observability is derived from Jean’s deep experience with specifications, but also her honest assessment of how we all see, use, don’t use, and often feel trapped by API specifications. It’s an API realm that on the surface feels deeply technical, but for me is actually more about API philosophy and getting at the realities of how and why we do APIs. Helping us see API change across our operations, but for me also helping us see API change across the API sector—-allowing us to better equipped to see and respond to change in how we conduct business internally and eternally using APIs.
