REST API vs. GraphQL: Comparison is not fair
To doc compares that GraphQL has only one endpoint while REST API has many. It also states that in GraphQL you can select exactly what items from the database you'd like to have.
However, you can write you REST API the exactly same way: Put everything in one endpoint and let the requestee decide on which items they'd like to receive. Now you might think that "well, then you need to implement all that logic inside the REST API endpoint.", but this is exactly what you need to do for GraphQL.
If this is a trap in order to find out which of the beginners actually paid attention, then I have nothing to complain. In any other case I think the comparison is not fair.
However, you can write you REST API the exactly same way: Put everything in one endpoint and let the requestee decide on which items they'd like to receive.
Then it stops becoming a REST(ful) design according to the original definition of REST — it's just a custom API design built on top of HTTP.
I see, we're talking on two different slates, I guess.
[Clarification] I thought the content was purely technical / functional. As I understand your response, the content is rather philosophical.
[Suggestion] I think it would be very helpful to point that out on the page.
[Background] I've had various encounters with people speechless after they realized that technically both approaches can do the same and "using one endpoint for all requests" is no pro for GraphQL. As of my experience most inexperienced people cannot grasp that already.
@stationname —
I wouldn't say this is philosophical — REST, as a term, has quite a specific meaning and conceptual model when it comes to API design.
Agreed that the content should probably provide more clarification (I haven't looked at it in detail, so can't comment specifically).
(Note: I'm not associated with this project)
I'm so happy we're talking about this, I struggled with the same things when trying to get my head around GraphQL versus REST. It seemed unfair to say "GraphQL has one endpoint and lets you pick fields" because you could build something similar in REST if you put your mind to it.
But @jits made a good point doing that pushes your API away from REST principles and into your own custom setup. I didn't quite get that at first. I also think @stationname is righ about making the docs clearer for newcomers. It would help people understand that this isn't just about what each one can do.