Well, you have to dive into the origins of REST to understand where it stems from and how you'd use it.

REST isn't describing a concrete implementation of an API. Rather it's a set of first principles that define an architectural style of API. So, it's more abstract then what people usually make out of it. As such, there's no single, definitive, end-all REST API that gets it "the right way". There's just a multitude of different interpretations, that each cater to a specific problem, or a set of problems.

REST is tied to HTTP for the simple reason that the person who came up with those principles, Roy Fielding, was also one of the architects of the HTTP 1.1 specification, back in the late 1990's. He developed his framework of ideas on REST as his doctoral dissertation, while working on HTTP 1.1 in parallel.

HTTP is a communication protocol, and as that was developed through RFC's and intense discussion, he had to boil down how the different concepts within the protocol - GET, POST, PUT, URI's, the structure of a HTTP message,... - could be ordered in a way that yields meaningful and efficient interoperability between systems. The REST principles are just one way that describe on a high level how you could lay out the constituent HTTP concepts to achieve just that.

https://en.wikipedia.org/wiki/Representational_state_transfe...

"Throughout the HTTP standardization process, I was called on to defend the design choices of the Web. That is an extremely difficult thing to do within a process that accepts proposals from anyone on a topic that was rapidly becoming the center of an entire industry. I had comments from well over 500 developers, many of whom were distinguished engineers with decades of experience, and I had to explain everything from the most abstract notions of Web interaction to the finest details of HTTP syntax. That process honed my model down to a core set of principles, properties, and constraints that are now called REST.[7]"

For all intents and purposes, REST doesn't concern itself with particular serialization formats, how you structure the data, how you validate data through schema's, how you structure URI's, how you process that data, nor what language or technology you use.

In my book, GraphQL is an entirely different beast which has little if anything to do with REST. The only thing it has in common with REST is that all communication happens over HTTP through GET and POST requests. But instead of using the constituent parts of HTTP itself to encapsulate meaning and salience, it just acts as a plain carrier of enveloped plain text messages represented as serialized JSON. In essence, GraphQL is just a query language much like SQL: you define a query, you submit it to a database, and you get a result back. It just happens that you interact with that service over HTTP.

You could even go as far and argue that a GraphQL service IS RESTful simply because it adheres to the HTTP protocol and resources can be dereferenced through URI's if only you're willing to stretch your own interpretation of the REST principles far enough.

Regardless, on a practical level, if GraphQL works out for you, then great, keep using it. Maybe you're just building a tiny web service with just a few URI's that yield static data, well, just consider modelling how clients interact with those URI's according to REST principles. Or maybe you simply have a plethora of libraries and tools in your toolbox that whipping up a lightweight GraphQL API takes far less time then conceiving and implementing our own HTTP endpoint. It's just a matter of preference and context. One isn't inherently better then the other, after all.

A lot of of people are indeed opinionated. They are also building those opinions on other people's assumptions and beliefs. Few people actually take the time to go back to Roy Fielding's dissertation or read up on the origins of the HTTP protocol and the REST principles.

In part, the confusion about REST also uncovers a structural problem: a big group of developers are well versed in building applications for the Web using modern tools and languages... but lack a foundational understanding of the protocols, the standards and the concepts that underpin the Web. This should also spark worry as the foundational principles of the Web, especially the openness of the standars, are being contested by the likes of Google i.e. their decision to hide URI's from users in their applications: https://www.androidpolice.com/2020/06/12/google-resumes-its-...