HTTP APIs, or as they are often referred to as REST APIs, are always the base layer for any API operation. This is where everyone should begin, but there are a number of other healthy patterns in use that teams should be aware of, and able to confidently implement. I began working working on this narrative back in March of 2017 with a Focus on Having a Robust and Diverse API Toolbox, which is something I kept expanding on in January of 2018 with My Evolving Definition of a Robust and Diverse API Toolbox, culminating in a talk that I gave at API Days Paris about APIs Not Just Being REST. I am thankful for Fran slapping me and reminding me that I shouldn’t fall under the spell of any single API design pattern, and that a diversity in learnings and implementations is critical to being successful in the API long game.
REST, SOAP, Hypermedia, GraphQL, WebSub, Kafka, and many other successful API patterns dot the landscape. REST is dominant because it is simple and reflects the web, but as many practitioners point out, it will begin to fail you in a variety of use cases. In the ongoing expansion of the API universe there has always been, and will always be, believers of a specific API pattern who like to say it is the one pattern to rule them all. Always avoid this people. If someone says that GraphQL will work in all situations, they likely don’t have very wide experience in the API sector. If someone says that SOAP is dead, they likely haven’t worked much within the enterprise or government agencies. If someone says your APIs have to be all be level-4 REST then they are likely are part of a cult of religious believers called RESTafarians. There is no single API pattern to rule them all, there are only informed and uninformed API practitioners, who are putting APIs to work across the factory floor of their organizations.
While I have been doing this work for over a decade now I still fall prey to the most attractive narrative of the day. This is how storytelling works. This is why you can’t just surround yourself with marketers or ego-driven evangelists like me, and you need to have people who get their hands dirty with different approaches to delivering APIs, regularly engage in conversations with folks on the ground within enterprise organizations, and aren’t afraid to correct you when you are using the wrong words or phrases to talk about the present or the future. Our words matter. With this in mind, the future isn’t event-driven, eventful, or other exciting pattern du jour, and as Fran said, the future is about having a diverse API toolbox. If you, or someone else is pushing your operations to be more event-driven in this moement, make sure you are thinking it through. Make sure you are asking the right questions, and have sufficiently stepped back and are able to see the big picture before you commit fully to setting things in motion. Even-driven can help you solve a lot of problems, but like any other pattern, if you haven't properly crafted a coherent strategy, you might just be creating more problems for yourself.
