I have been working to understand REST, WebHooks, GraphQL, WebSockets, MQTT, Kafka, and gRPC side by side as protocols and patterns, but also as the specification that define them like OpenAPI, AsyncAPI, Protocol Buffers, and Postman Collections for about six years solid now, with another five years previous studying what it meant to have a diverse API toolbox. I agree that enterprise organizations will need a multi-protocol approach to API governance, but I am making the executive decision that I am exclusively going to focus on just HTTP APIs and Webhooks—excluding GraphQL, WebSockets, MQTT, Kafka, and gRPC from my work. It is too much. Too diverse. Too many competing ideologies. I am determined to get a handle on API governance as a discipline, and believe that focusing on anything beyond HTTP APIs and Webhooks to be a distraction.
Even with the growth in usage of GraphQL, WebSockets, MQTT, Kafka, and gRPC, and a clear need to use these patterns and protocols, as well as a need to govern, the need for governing the sprawling chaotic landscape of HTTP APIs and augment with purposeful Webhooks is significantly greater. I will leave governing these areas to other experts. I am sticking with governing HTTP APIs and Webhooks, and telling my customers that they should focus on their ubiquitous HTTP API operations, and get their house in order across the enterprise before investing too heavily in other technologies without a clear customer and business mandate. I am tired of the fragmented conversations and competing interests from these other patterns and protocols, while the rest of, and the larger portion of API operations is still such a mess after all these years. I am going to stick with mastering the fundamentals when it comes to HTTP APIs and Webhooks, and provide the focused and dedicated support I think that enterprises are needing amidst the API sprawl and chaos.
I know that GraphQL has its place. I get it. But I’ve also seen it implemented too many times when nobody needed it or asked for it. I know that WebSockets and Kafka have their place, but I’ve also seen too many people go from zero to Kafka without even considering simpler Webhooks to manage events. I know that GraphQL, WebSockets, and Kafka are in need of governance, but I am tired of HTTP API governance lagging behind and suffering because we are trying to do too much. I am looking to move forward the discipline of HTTP API and Webhooks governance in a meaningful way at scale. I am interested in moving forward the conversation around the platform, lifecycle, and policies of API governance for HTTP APIs and Webhooks. It is ridiculous that enterprises are still struggling with the fundamentals of a technology that is so ubiquitous and powers such a large part of their business. There is a lot of work on the table to make our APIs more discoverable and consistent, and I think that a focus on the business and technology of the dominant API pattern out there when it comes to API governance is in order.
So, I am not going to do multi-protocol API governance. I am staying focused, and leaving the other work to those who get those areas better than me. I am confident that HTTP APIs aren’t going anywhere before I reach the end of my career. I am confident that I can be more successful in my work, and help my clients be more successful in their operations by staying 100% focused on HTTP APIs and WebHooks. I think we are entering an era of technology where things have to become more simple, consistent, and well-known as we leave the juvenile period of APIs. HTTP APIs are simple, cheap, and ubiquitous—they make sense to many developers and reflect our adoption of the World Wide Web. This is what I know, and I’d like to help improve the quality, reliability, and consistency of APIs at scale. I think I can help significantly contribute to a better API world with APIs.json and API Commons properties, helping standardize APIs based upon what is already out there, as part of my work to profile HTTP API and Webhook patterns for APIs.io.
