This course has been updated! We now recommend you take the Server-Side GraphQL in Node.js course.

Check out a free preview of the full Introduction to GraphQL course:
The "GraphQL vs REST" Lesson is part of the full, Introduction to GraphQL course featured in this preview video. Here's what you'd learn in this lesson:

Scott contrasts GraphQL and REST because the two are often confused.

Get Unlimited Access Now

Transcript from the "GraphQL vs REST" Lesson

[00:00:00]
>> Scott Moss: So GraphQL versus REST. So if you've taken the REST course, you know what REST is. If not, just try to follow along here, but REST is a different type of interface for building APIs, and GraphQL is just a query language in front of it. So I just wanna compare the two to try to give people the differences.

[00:00:19] So they're different but they're actually kinda similar at the same time. They do similar things but they do them completely different. So GraphQL only has one URL, that's it. Your APIs only gonna have one URL. There's no more, create a different path for every single resource with the verb combination, that's gone.

[00:00:38] That's what REST does. GraphQL is just one URL and mostly just one verb, you'll mostly just do a post request the whole time. You can do a get request for queries, but for mutations which are rights and updates, you can't really do a get request, you gotta do post.

[00:00:53] So yes most of the times it's gonna be a post request with one URL, that's it, and that one URL is capable of every single thing. Whereas, like I said, REST is a resource and a verb combination. And for every resource you have, there's multiple routes. So that's why in REST, sometimes you'll see a API that's like /API/V3 cuz they had to version the URL because they changed the API.

[00:01:18] Well, don't have to do that in GraphQL cuz it's always the same URL. And you just change the schema. So you don't have to version the URLs anymore. So it kinda gets rid of that.
>> Scott Moss: In REST, the shape and the size of the data resource is determined by the server.

[00:01:35] So basically what that means is, when you build your REST server, when you create those resourceful, those routes for the resources and then you create the controllers for them. What is gonna be sent back from those controllers is determined by whatever code you write in those controllers, right.

[00:01:51] Whatever you query for the data is asked what's gonna be sent back. In GraphQL, the shape and the data and the size of it is determined by the request that's coming in. So whatever request or query that's being sent to the server, whatever that's asking for, that's what the server has to fulfill.

[00:02:07] So if a query is only asking for a user's first name, it's only gonna resolve the first name. If it's asking for the first name and then the last name and then the ID and then it's favorite articles and then it's best friend, then it's gotta resolve all those as well.

[00:02:21] So it automatically will do that once you set all your resolvers and stuff up. So that's the difference between REST and GraphQL when it comes to resolving data. REST is all hard coded, right. All the controllers and values are hard coded whereas GraphQL is dynamic. You have no idea what a query is going to look like.

[00:02:39] You just know that it's gonna stick to the schema that you created. And it could be anything. They can ask for anything within these bounds. And your server has to be able to respond to the different combinations of the queries that are being sent, so it's all dynamic.

[00:02:51] The data, the shape of data is dynamically generated at runtime versus being hard coded like it is in REST, if that makes sense.
>> Scott Moss: In REST you have to, no, make, you have to make multiple API calls to retrieve relational data. So, for instance if I have a user that relates, I'm sorry, let's say we have author model and it relates to blog post.

[00:03:18] So in the REST model if I wanna get the author and all of his blog posts, one I have to make a call to author, and then get the blog post IDs. And then grab all those ID's and make other calls for all of those, whereas in GraphQL I can do that in just one request.

[00:03:33] I can just say give me the author, and then fulfill all the blog posts and give me those and then give me the titles for those, and resolve that all the way down. I get all of them in one request without having to make multiple round trips with the server.

[00:03:46] So that's a big difference there as well because GraphQL will traverse the query that's being sent and proceed to the resolvers to go ahead and resolve all those fields for you. And that's why it's called GraphQL, because it's like a graph.
>> Scott Moss: In REST, the shape of the response is determined by whom ever created the server.

[00:04:08] And like I said, in GraphQL it's determined by the query. So again, whatever the query is being sent, that's what the shape of the data is gonna be. In REST a single request will execute on the controller in the server. In GraphQL a request might execute many resolvers on the server.

[00:04:25] So for REST if I say give me the user with this ID, that's ultimately going to execute one controller that ultimately gets this user with this ID. But in GraphQL if I say give me the user with this ID, that could potentially be three resolvers. You don't know the resolvers yet but its basically like a controller.

[00:04:42] But basically what I'm saying is, you have no idea how many of those functions on your server are gonna run, because it's determined by whatever the query looks like, and not so much about what you hard coded. So again, not only is the data and the shape gonna be dynamic, but the functions that run as callbacks to your request are also gonna be dynamic, as well, as far as, in what order that they run and how many of them run.

[00:05:09]
>> Scott Moss: Any questions on this? Do not expect you to understand all of this right now. It's just telling you what you're about to get into.
>> Speaker 2: The other thing I'm thinking is that, that this could be compared also to like a SQL, right?
>> Scott Moss: Yeah.
>> Speaker 2: I know SQL is just data, it's not just data but-

[00:05:25]
>> Scott Moss: Actually, you could definitely compare GraphQL to a query language like SQL because it is a query language, SQL is a query language, GraphQL is a query language. So yeah, you could say GraphQL is like SQL fr your API, all right. Instead of being SQL for your databases it's like SQL for your API, all right.

[00:05:42] So yeah, if you did a SQL query it's a database, you're only gonna get back what you asked for, all right, and same thing with GraphQL. Yeah.
>> Speaker 3: Yeah so, I've read that GraphQL, there's just one endpoint whereas with REST there are all these different endpoints like kind of a-

[00:05:58]
>> Scott Moss: Yes, there's only, you're only gonna ever have one endpoint. There's no point of having more than one endpoint and that's because in GraphQL the information that it needs, it's not so much in the URL, it's in the body that you send up. As you'll see when we start writing queries, you're gonna send a query up to your server.

[00:06:17] And that query's the information that the server needs. That query has nothing to do with the URL. It's just a string. And, like I said, you can encode it. Like I said, you can put it in a get request sometimes. But, when you have to do a mutation, as in you've got to send variables to the server, you can't put those in the URL.

[00:06:33] So, most of the time it's just a post request.