I thought this would be about APIs as in APIs, that is the general concept which goes back decades, not REST APIs. This sounded like a much more interesting piece on the history of software development in the old days.
My largest gripe with REST is that it's a very lock-in technology. Once we evolve past REST instead of being able to decouple cleanly from the underlying protocol, we're pretty much trapped in status codes and methods that lock us in. At least with GraphQL there's a clean break. Everything should have been focused on the payloads, not the transport layer.
> My largest gripe with REST is that it's a very lock-in technology.
I can't really think of a technology less subject to lock-in than REST; reliance on specified resource representations and HATEOAS makes it agnostic to pretty much everything.
EDIT: I guess there's lock-in in the sense that once you have REST, everything else is too limiting.
> Once we evolve past REST
Few things even reach REST, much less evolve past it.
> instead of being able to decouple cleanly from the underlying protocol
REST starts out decoupled from the underlying protocol(s), it's not something you need to do when evolve past REST.
> Everything should have been focused on the payloads, not the transport layer.
The only thing that REST says about the transport layer is that one should avoid altering or extending the semantics of the underlying transport protocol(s) except as necessary to cover gaps that have no suitable coverage. REST is all about the payloads plus HATEOAS.
On top of what others have already said: GraphQL is a "clean break" that breaks with everything: idempotency (POST requests are not idempotent), caching (POST requests cannot be cached), version control and partial updates (GraphQL eschews ETags), etc. etc. etc. There is value in underlying protocols and there's value in using those protocols. GraphQL servers end up re-implementing, poorly, half of HTTP, and patting themselves on the back for it.
I'm not sure what's your personal definition of REST but REST according to Roy Fielding's definition is an architectural style that helps design APIs that are as loosely coupled as it gets. In fact, I'm not sure what style of APIs you feel improves upon REST on this criteria.
REST is an architectural style and while the decision to use the style may lead to "lock in", it in and of itself does not given it's a choice to use it or not.
I sometimes discover these old protocols when I am testing things on localhost and using traditional netcat. The original nc does automatic reverse DNS lookups. rje was assigned port 77. I knew about rje from using port 77 but I had not read this.
