I am always fascinated by the dogma that exists around each successful API pattern that comes along. Everyone believes their “aha” moment is elevated over everyone else’s “aha” moment. I’ve been guilty of the same response many times over the years. It takes practice and time to be able to elevate yourself over the dogma and see the value and benefit of any individual API pattern, and even then you’ll still be subject to being sucked back down with new trends, and peer pressure along the journey.
I am hyper-focused on producing API products right now. While this will mean many different things to many different people, I believe in the importance of negotiating a strongly typed way of defining a lifecycle that works for product and engineering on the producer side, as well as something that is inclusive and successful at engaging with API consumers. This is something that is essential when approaching standardized APIs that employ a diverse set of API patterns that will matter to both the producer and consumer sides of the same API coin.
When you witness first-hand the impact of REST, GraphQL, Kafka, or gRPC, you tend to become a believer in that technology, and if you don’t elevate yourself outside that paradigm on a regular basis, this becomes the norm for you. Technologists love finding solutions. We are good at it. Once we find them we tend to cling to them, unless we are elevated and shown a different perspective. It is important that you explore the good and bad of each pattern, and see it shine and fail, so you understand the nuance of each approach, but also how they all fit into the bigger picture.
I’ve worked with many of the groups of people involved in the leading API patterns over the years. We are all a bunch of opinionated assholes. Myself included. People who champion specific technologies within enterprise organizations tend to be very opinionated, which can be even more problematic when they do not possess proper feedback loops with internal or external consumers. In short, the difference between designing the perfect API solution, and successfully operating a solution in product with consumer adoption, will make or break you, reflecting how much you are able to rise above your API dogma.
I am a big fan of HTTP APIs. I’ve seen the potential of GraphQL in some situations. I’ve experienced how event-driven approaches can make API operations more impactful and meaningful. I also have a strong grasp on how a formal API product definition, standardized API lifecycle, and robust API governance can shape whether you need REST, GraphQL, Webhooks, WebSockets, gRPC, or other pattern. This post is just a reminder for me to make sure that I regularly do the work to rise above the API dogma while evaluating 2K+ APIs I’ve profiled so far as part of my APIs.json work, so that I can see things from the perspective of both the API producer and consumer, without bringing all my own personal baggage along for the ride.
