It doesn’t matter what your API design processes are, and what tools you are using if you cannot do it reliably. If you aren’t monitoring, testing, securing, and understanding performance, consumption, and limitations across ALL of your API infrastructure, then there will never be the perfect API solution. If your web API infrastructure isn’t reliable, consumers will not build trust, increase the depth and scope of their integration, making a successful API toolbox more about doing APIs well, than it will ever be about any particular protocol, technology, and proprietary solution.
Web APIs, hypermedia, GraphQL, Webooks, Server-Sent Events, Websockets, Kafka, gRPC, and any other approach will always be inadequate if you cannot reliably operate them. Every tool within your API design toolbox should be able to be effectively deployed, thoughtfully managed, and coherently monitored, tested, secured, and delivered as a reliable service. If you don’t understand what is happening under the hood with any of your API infrastructure, out of your league technically, or kept in the dark through vendor magic, it should NOT be a tool in your toolbox, and be something that left in the R&D lab until you can prove that you can reliably deliver, support, scale, and evolve something that is in alignment with, and has purpose augmenting and working with your existing API infrastructure.
The reliability of your API infrastructure will be defined by our API toolbox, and how mature your approach to stabilizing API infrastructure is. Ensuring that your API infrastructure is reliable should be the first priority over and above any specific design pattern, protocol, or technique. This stability should be applied across the entire toolbox, and provide the same levels of awareness, accountability, and stability across HTTP APIs, webhooks, Server-Sent Event (SSE), Kafka, or any other implementation. Ensuring that each team’s approach to delivering APIs, no matter what the type of API being delivered, can reliably deliver within service level agreements (SLA), and meet the different levels of consumption by internal, partner, and 3rd party groups who are putting enterprise digital assets to work.