My main qualm about REST is the number of inputs for doing something: Path variables, query variables, POST input, headers and for shits and giggles the Http METHOD. To top it off, because people want "beautiful" REST APIs everyone has a playground to do these kinds of things differently. And boy are they done very differently from company to company. And that leads to massive opinionated people. Finally, REST is tied to HTTP too tightly. It can't be independent of it, ever. I know a lot of people believe that's a good thing, in that there are metrics, logs, and a variety of data that assists architecturally. But it has only reached that status because we're sitting at 15 years of REST toolchains.
I'm not saying GraphQL is the long term answer, but personally I'd rather be in a project using GraphQL (and hopefully not backed by REST at all)
This is partly because REST is not a standard like GraphQL, and you can't really treat them as being equivalent.
If you want a closer comparison, I think it's better to look at standards like OData, JSON:API,or even just for example [Microsoft REST API guidelines](https://github.com/microsoft/api-guidelines).
REST by itself is a pretty general description of a type of architecture that isn't even tied to HTTP. Even HN by most definitions is a REST service that primarily uses `text/html` as it's format.
My main qualm about REST is the number of inputs for doing something: Path variables, query variables, POST input, headers and for shits and giggles the Http METHOD.
As a sibling comment has already extensively described why this is the way it is, I want to add one more thing: REST is a set of principles leveraging what already exists in HTTP. And HTTP gives you a lot. Here's an extensive HTTP decision diagram with links to explanations on basically everything: https://github.com/for-GET/http-decision-diagram/tree/master...
Caching? HTTP got you covered. Editing conflicts? HTTP got you covered. A decision path for auth? HTTP got you covered. No-op requests? HTTP got you covered.
Meanwhile GraphQL libs are busy reimplementing half of HTTP spec inside a single POST request.
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.
"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-...
Comments
My main qualm about REST is the number of inputs for doing something: Path variables, query variables, POST input, headers and for shits and giggles the Http METHOD. To top it off, because people want "beautiful" REST APIs everyone has a playground to do these kinds of things differently. And boy are they done very differently from company to company. And that leads to massive opinionated people. Finally, REST is tied to HTTP too tightly. It can't be independent of it, ever. I know a lot of people believe that's a good thing, in that there are metrics, logs, and a variety of data that assists architecturally. But it has only reached that status because we're sitting at 15 years of REST toolchains.
I'm not saying GraphQL is the long term answer, but personally I'd rather be in a project using GraphQL (and hopefully not backed by REST at all)
This is partly because REST is not a standard like GraphQL, and you can't really treat them as being equivalent.
If you want a closer comparison, I think it's better to look at standards like OData, JSON:API,or even just for example [Microsoft REST API guidelines](https://github.com/microsoft/api-guidelines).
REST by itself is a pretty general description of a type of architecture that isn't even tied to HTTP. Even HN by most definitions is a REST service that primarily uses `text/html` as it's format.
As a sibling comment has already extensively described why this is the way it is, I want to add one more thing: REST is a set of principles leveraging what already exists in HTTP. And HTTP gives you a lot. Here's an extensive HTTP decision diagram with links to explanations on basically everything: https://github.com/for-GET/http-decision-diagram/tree/master...
Caching? HTTP got you covered. Editing conflicts? HTTP got you covered. A decision path for auth? HTTP got you covered. No-op requests? HTTP got you covered.
Meanwhile GraphQL libs are busy reimplementing half of HTTP spec inside a single POST request.
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-...