HTTP Web APIs are the dominant form of private and public APIs. It has been this way for over a decade, and will continue for some time to come. I know that GraphQL, gRPC, Kafka, and other API believers feel confident they will displace their simpler HTTP variant, but I am fairly confident they won’t when it comes to externally available 1st and 3rd-party APIs. HTTP Web APIs, or often called REST, RESTful, or RESTish dominate because they are simple (most of the time), cheap, and messy—-just like us humans who are producing and consuming them.
As someone who embraces computational thinking it is easy to strive for perfection, and always completing the algorithmic puzzle we have in our head. However, Boolean, 1 or 0, and the computational way of life that comes with it is just one system for defining how the world works–granted, it is a pretty expansive one, but one that has limitations. Whether it is control over the relationship graph, events, speed, volume, and the other myriad reasons we choose GraphQL, gRPC, Kafka, and other patterns, HTTP and now HTTP/2/3, combined with simple JSON will get you a long ways down the road you seek, if you just take the time.
I get why people choose GraphQL, gRPC, Kafka, and other protocols and patterns–they most definitely have their place and usage. However, I also see people go from zero to these patterns and protocols without ever properly learning and designing using simple HTTP + JSON, using the available patterns we have like REST & Websockets. To help enterprises focus I am going to be the guy who focuses 100% on RESTful, RESTish, and HTTP, Web, and Websocket APIs, sharing stories, conversations, and guidance from this important dimension of the API economy. I will leave the other patterns & protocols to those experts, and stay focused on helping enterprises define and optimize their HTTP API supply chains, factory floors, and distribution channels.
REST is messy just like us humans. This is why I believe in it. I don’t think there are perfect technical solutions, just ones that get used and ones that do not. I don’t think everything needs scale and performance. Some do, but most don’t. I prefer API technology that speaks to the masses over API technology governed by a few. I get why REST APIs drive folks nuts, it does me as well from time to time. But so do people. I also see people not spending the time to get to know HTTP, REST, and WebSockets before they move onto the next cool shiny technology. I also see API producers spend a huge amount of time avoiding getting to know the people involved in consuming their APIs, and assuming the right technology will always win–which isn’t how all of this works.
