GraphQL is arguably consistent with actual REST, but its a replacement for trivial JSON CRUD over HTTP, which is one of the common abuses of the term “REST”.
GraphQL is arguably consistent with actual REST, but its a replacement for trivial JSON CRUD over HTTP, which is one of the common abuses of the term “REST”.
It does not have to be a POST request or even HTTP. The point about the 200 status code is correct.
The confusion comes in when are talking about what happens at on the graphQL server and the calls it makes.
Say for example your browser code makes a single graphQL query to a graphQL endpoint - that server in turn can generate multiple REST-full service calls, file reads, in-memory cache retrievals or whatever to fulfill the graphQL schema as determined by the incoming graphQL query.
All that was initiated by a single graphQL query (a single POST) from the client. What do you report back to the client if one out of the three server-side REST calls fails? Depending the schema, your initial query is still successful, it's just that one of the fields is empty or NULL (again depending on the schema). So that by any reasonable definition is still a 200. Even if all service calls failed, if your schema allows for fields to be empty or NULL, it can still be considered successful.
All that is to say that graphQL is not a replacement for REST, it's an enhancement that serves as a negotiable schema between client and service, a data orchestration layer that can stitch together multiple data sources into that schema, and as a pretty robust way to think about what to present to the user in error conditions since every field you want in your query, presumably, serves in the UI in some way. It gives you the tools to intelligently handle when those fields are not available.
You can do that with vanilla REST calls of course and roll your own solutions to the problems graphQL solves (or tries to solve).
I can do that in any Django view, REST or otherwise. How is that unique to Graphql? I really can't see what I gain. You define your response in Swagger or you do it in Graphql.
I was explaining why graphQL isn't a 1:1 replacement for REST because of that.
I feel like you are hearing an argument that I am not making. Use whatever tool is best for the job / infrastructure / business needs. If that's Django cool. GraphQL has its place too.