I’ve never ceased to be amazed by the recurring hope that “the next new thing” will solve all our problems. In 40+ years of designing and building software, it seems to me that corporate IT cultures refuse to get serious about the word engineering in software engineering.
Today’s software and data systems are complex machines made up of many thousands, if not hundreds of thousands, of lines of code. They are required to meet high standards of reliability, accuracy, and performance. There is no magical way to build them without knowing what you’re doing. Unfortunately, it takes knowledge, skill, and intellectual discipline to build them well— it takes engineering. When you instead rely on wishful thinking and self-delusion — pixie dust — you get what Boeing got with the 737 Max’s flight control software. You wouldn’t try to build an airplane or Mars rocket without aeronautical engineering knowledge and discipline. Why on earth do we try to build software systems of equivalent (or greater) complexity without software engineering knowledge and discipline?
Representational State Transfer, REST, is a well-conceived architectural pattern that, if properly applied to API design, exploits the way HTTP communications work over LANs and the Internet, and the way high-performance Web servers function and cache data. It is not Roy Fielding’s fault that most of the developers of “RESTful” APIs fail to grasp the the nuances of his dissertation. The author’s criticisms of REST: 1) proliferation of endpoints, 2) over and under-fetching data, and 3) the need for versioning; have nothing to do with REST and everything to do with the deficiencies of individual REST API implementations and the the very common failure to understand the REST architectural pattern.
In reality, REST has only one endpoint, the “network” and uses URLs (just like Web browsers) to locate target resources. This is the infinitely extensible model that has made the Internet so powerful. There is nothing inherent in REST that drives “over” or “under” data fetching. That is entirely a function of how designers choose to describe target resources. In fact, the REST architectural pattern emphasizes optimizing network caching for performance. Finally, the REST pattern says nothing about versioning. The need to support multiple simultaneous versions is forced upon system designers by the very nature of modern distributed systems. A system implementer ignores versioning at his/her own peril. Simple logistics make it impossible to simultaneously update multiple data centers spread all over the globe. Distributed systems must transparently accommodate differences in definitions where possible and, at the least, avoid data corruption and recover gracefully when those differences cannot be accommodated.
In conclusion, REST and GraphQL are conceptually different things and serve fundamentally different purposes. Comparing them is even more nonsensical than comparing apples and oranges. At least apples and oranges are both fruits. If we developers are ever going to climb out of the holes we keep digging for ourselves, we need to stand on the shoulders of the greats who came before us like: Alan Kay, Roy Fielding, and Werner Vogels. We need to learn from them and become real engineers.
