Out of curiosity I start to read about GraphQL. Based on the samples on this article, it looks like REST API request to me. Is it stateless? means it has no request, no response from the server? If yes, then how come it is more resource lighter than REST API?
问题:
回答1:
Is it stateless?
Yes, in so far as the server doesn't require any knowledge of client state to correctly interpret the request; all of the necessary information is included in the request itself (headers and body).
It looks like REST API request to me.
It probably doesn't. It fails utterly on the hypermedia constraint (the specification lacks any reference to links, which is a big hint). It's a bit muddled on "resources".
From graphql.org
HTTP is commonly associated with REST, which uses "resources" as its core concept. In contrast, GraphQL's conceptual model is an entity graph. As a result, entities in GraphQL are not identified by URLs.
So you get a number of different URI that point to representations of different subsets of the entity graph, and a single URI used for all modifications of the graph. Behind the uniform interface, these "resources" will all be implemented using a single route.
REST is an architectural style, "chosen for the properties they induce on candidate architectures." It looks as though GraphQL is interested in a different set of properties; which is to say they are trying to solve a different kind of problem.
回答2:
GraphQL is often referred to as more efficient than REST because it allows clients to ask for multiple resources in one request, which saves round trips, and also allows clients to filter down to only the fields they actually need. So at the end of the day the way requests are done seems similar, but the more powerful query language allows the client to get exactly the data they need and no more.
And yes, it's stateless just like REST is. In fact some might say that GraphQL meets a lot of the original requirements that REST described.