Interesting writeup, but I’m still not sold.

Next, the author assumes that REST implies crude, atomic, primitive architecture. That’s just not the case. REST means a large variety of…

Interesting writeup, but I’m still not sold. To begin with, nowhere in this article does the author mention HATEOAS. That’s a glaring omission, because HATEOAS is what makes REST so powerful. GraphQL doesn’t offer that capability (at least I wasn’t able to glean such possibility in GraphQL).

Next, the author assumes that REST implies crude, atomic, primitive architecture. That’s just not the case. REST means a large variety of resources offered by the server, with each resource being purposefully designed to offer all the necessary information that the client needs in order to determine its next move. We call that an in-band information. All other tech invariably requires an out-of-band information that the client must obtain before the client knows what is the next possible move, given some circumstances. All such architectural styles end up being brittle, difficult to scale, difficult to maintain, troubleshoot and debug.

Versioning is a perennial problem in software (digital rot never sleeps), so anyone who claims they have solved this problem is being delusional.