I like researching and thinking more about each of the 13 AsyncAPI protocol bindings. It paints a picture of the past, present, and future of APIs for me. Leveraging AsyncAPI to define your event and message driven APIs is the future of API development, but one of the things I really, really, really, love about AsyncAPI as a specification is that the definition for the HTTP binding is just OpenAPI. Similar to how OpenAPI and AsyncAPI have baked in JSON Schema, AsyncAPI has baked in OpenAPI. In my opinion, this is how API specifications should work. There shouldn’t be one specification to rule them all, we let API specs compete on usefulness and the tooling that is built on top, and build on top of the specifications that already exist, preventing us from reinventing the wheel.
This kind of extensibility and reuse is what APIs are all about. This isn’t a question of OpenAPI vs. AsyncAPI, it is a question of AsyncAPI and OpenAPI. I know there is a lot of investment going into thinking about OpenAPI overlays for the next version, but as we have these thoughts I want to make sure this type of reuse gets considered. I am thinking very deeply about OpenAPI again, but I also find myself thinking very deeply about a number of API, data, and other operational level API specifications, and how they all work in concert. I am also thinking about where we need potentially new specifications, industry level specifications, and trying to find the bandwidth to continue talking about the future of APIs.json providing an index for all of API operations. OpenAPI, AsyncAPI, JSON Schema, and Postman collections have come a long way over the years, and I feel pretty poised to radically move forward how the API factory floor operates within the enterprise.
I learned a lot about the technology, business, and politics of APIs by participating in the evolution of API specs from 2010 through 2015, and was able to level up this knowledge working with API providers, and service providers from 2015 through 2020. Moving forward, I am wanting to inject more energy into the conversation, and help guide more money into proprietary and open source services and tooling that leverage API specifications. 2010 through 2020 showed me how slow these cycles really are for enterprise organizations, institutions, and government agencies, despite all the dust that gets kicked up by investment capital and storytelling by the tech sector. API specifications help me keep my eye on the prize on my own and I feel pretty strongly that they help enterprise organizations get their act together when it comes to doing APIs across teams and projects. API specification literacy will become a critical aspect of API operations in the next decade, and entire organizations will be defined by how well they define, collaborate, and communicate using API definitions. I can pretty quickly size up the nimbleness and agility of a large organization based upon whether they say "Swagger" or "OpenAPI", and whether they know about AsyncAPI, and utilize JSON Schema and Postman collections across operations. These specifications are essential to doing business online today, and tell a lot about what is going behind the scenes at any enterprise organization.
As we continue our march forward with the development and evolution of API specs, as well as the services and tooling that leverage them, let’s make sure we are thinking about interoperability and reuse. Let’s make sure we know how the specifications work together, and make sure all services and tooling we develop wisely put existing API specifications to work. Let’s understand and put to use in ways which the specifications reuse each other and prevent ourselves from reinventing the wheel in our work—even if a specification doesn’t do everything you need. I think that OpenAPI provides us with a wealth of reuse opportunities within the HTTP 1.1 realm, but AsyncAPI has come along as a sister specification to show us how this can be done beyond HTTP 1.1. Building on OpenAPI and JSON Schema to help guide us into the future, allowing for reuse of existing patterns, but also pushing us to continue to acknowledge that HTTP APIs will only get us so far, and we will need a diverse set of bindings to keep our API factory floors operating.
