REST vs GraphQL - What's the best kind of API?

when you're working with web apis in web development you typically have the choice between rest apis and graphql apis at least if you're the one building the api you can choose which kind of api you want to build now there are some misconceptions regarding these apis for example people thinking that graphql apis can only be used with react frontends which is not the case and therefore in this video we'll have a look at the differences between these two api approaches we'll also have a look at what they have in common and therefore hopefully by the end of the video you have a better understanding of what the concepts behind the two apis are and when you might want to work with which so what's the idea behind rest apis and graphql apis well in general when i talk about apis here and therefore i of course mean apis that we expose on some servers so in the end a web api to which you can send http requests from some client be that a web page or a mobile app then that means that we have a web service which exposes certain entry points you could say where clients as i said web apps mobile apps can fetch data or send data to and for building such a web service you typically follow one of these two approaches you either build such a rest api and use the concepts related to that or you follow that graphql api approach and build your web service in that way in both cases in both scenarios you have a web service but how you build your web service also influences how the client queries that service or uses that service so which code needs to be written in the client app but back to rest api versus graphql api a rest api embraces the concept of having multiple endpoints which means multiple urls are exposed by your web service to be precise urls or paths on that domain where you host that web service that react to different http methods different http works being used in the requests that reach that web service now a graphql api on the other hand works with one endpoint only which always is reached with a post request and you can name it whatever you want but often it's yourdomain.com graphql so that's one crucial difference multiple endpoints versus one endpoint and i'll dive deeper into this in a second now in both apis you typically exchange json data though i will say that with the rest api you also might send back binary data you also can implement something like that in a graphql api where you for example also provide a separate endpoint that returns a file but typically json data is exchanged so that's pretty much the same also the same is that you can use any server-side language and framework and also any front-end language and framework when working with a rest api and also when working with a graphql api so you can build that api on a server on the backend with any programming language you want with php with node with java with python that really doesn't matter you can use any language you want and on the front end you can also use any technology you want you can be building a mobile app with swift you might be building a web app with angular or react that does not matter and i'm emphasizing this because a common misconception with graphql since it was invented by facebook is that you have to use react in order to communicate with a graphql api and that's just not correct any front end can be used because in the end it's just about sending the right http requests to the web service also common for both apis is that they're stateless which means they don't care about the exact client to them for example you don't see session based authentication approaches being used there because you don't store any data about the client on the back end there you just expose these endpoints and whoever sends the right kind of request possibly combined with some authentication logic like some attached token whoever sends a correct request gets the data or may store some data depending on what you expose on your api so that's the rough overview let's take a closer look the core difference between these two kinds of apis really is how you send requests to them in the rest api as i mentioned you work with multiple endpoints that means multiple paths multiple urls you could say that are exposed by your server for example you could be sending a post request to yourdomain.com user and attach some json data which holds such a object in the end such a key value pair with a name and a value for it of max that could be a request you send to a rest api and to that same api you might also be able to send a get request to a different path to get all users so it really is up to the creators of the api to decide to which paths for which http words you can send which data and these are the three important pieces that make up such a request here you have a http word you have your path and you have the request body you might need to attach of course not all requests need such a body for example get requests don't include a body so that's how you communicate with a rest api and again it's the creators of the api that define which endpoints so which paths for which http works are available and if you send the request to a path or with an http work that is not supported you'll get back an error now for a graphql api as i mentioned we have one endpoint and that endpoint can have any path you want often it's slash graphql it always takes a post request though so where a rest api is flexible and supports get post patch put delete and so on graphql apis only work with post because in a graphql api you don't target different endpoints different urls instead you state what you want in your request body and therefore the http work has to be post the path is always the same and these two things are fixed because it's your request body which includes a query language a command which graphql which the graphql api on the back end is able to parse because the graphql query language which in the end is encoded in the request body that is standardized and therefore there is a common understanding on how it should be parsed which commands you can use and hence the graphql api so the server is able to parse the incoming request and understand what you want almost like how you query a database with sql or with mongodb or whichever database engine and query language you're using the same logic applies here just always keep in mind you're not talking to a database here you're still talking to a web service which then just does this parsing for you and then the web service so the back backend the app you wrote on the backend goes ahead takes that parsed command and does whatever you define on the backend that again is really up to you as the developer of the backend to decide what happens for an incoming query of this type of that type or of a totally different type so let's zoom in a bit and let's start with the rest api there you learned it's all about client server communication and on that server you can do whatever you want work with files reach out to a database run some complex logic which you can't or don't want to run in the client app and so on and just to emphasize this again client could be a web app could be a mobile app server is well your server using any server side language you want now from the client you can send requests to the server and such a request has to be structured with a certain path with a certain http word and possibly then also some body that needs to be attached to some of the requests like for example to post requests but you're not limited to post requests you can send get requests patch requests and so on and also to different endpoints all the endpoints that can hold dynamic segments which you then parse on the server to find out what the user wants which resource should be retrieved so you could say that in a rest api your api endpoints in the end map resources map actions that happen on the server for example the action to get all posts or to create a new post to certain url http word combinations and as i mentioned it's more than just get and post on a rest api you really have support for get post put patch also delete and also other http words like options which is rarely one you directly use though instead that's typically automatically sent by the client and not really important here of course i do have a complete series here on this channel where i build a rest api from scratch with you with nodejs and i can only recommend that you check out this series to learn more about it and get a feeling for how you build such an api how it works how you reach out to a database there and much more so what about graphql there well unsurprisingly hopefully we have the same base setup client and server which want to talk to each other server is responsible for any server side logic database access and so on i also have a video why clients don't directly talk to databases by the way that might be interesting to you as well all these extra resources are of course linked in the video description and now if we come back to the graphql api the question is how do we send the request there now as i said you don't have multiple endpoints instead you have one endpoint which always takes a post request because that one request which you send is not targeting specific actions on the server by the combination of url and http word instead it's the query expression that's part of the request data so of the request body which is then parsed by the server so that the server is then able to do something to retrieve the data you need a graphql query so such a query expression which you might include in the request body typically looks like this and i also have a complete series on this channel where we build a graphql api from scratch just as with the rest api so also check out this graphql api series if you want to learn more about that also check out my node.js complete guide course there i dive into both in one course and of course not just into that but into node.js and express and all of that from scratch so that might also be worth a look back to the query such a graphql query is typically made up of an operation type which you specify there you have three important types query which means you want to query for some data you want to get some data but you also have mutation and subscription which means with mutation you want to edit some data you want to store new data or added existing data on the server with a subscription you want to set up a live subscription so that the server actively informs you about changes that happened there now this will not be possible over the normal http protocol for that you will need websockets instead now back to that query we know the operation type now then you give that operation an identifier you could say you could say an endpoint this is important for the server to understand with which resource you want to work and of course you can't send any arbitrary queries let me really make that clear as you learn in my graphql from scratch series you'll see that on the server you of course parse that incoming query but then you only support a couple of endpoints or a couple of resources that can be targeted you don't want to make everything mutatable or you don't want to allow the client to query for any kind of data you on the server when you define the graphql api when you write the code there you don't just parse the incoming query you also then define what you do with the parsed result and which kind of queries you want to support so to say well last but not least if we go back to the query we know what we want to do query data or mutate data which kind of data we'd like to get or mutate and then for that specific data we also specify which fields we want to work on so which fields we want to get back for example and that's one of the huge advantages of graphql compared to rest apis with rest apis you target a specific resource for example get posts and you retrieve all posts with all fields that belong to a post so with the id the title the description and so on you might use query parameters to implement something like pagination to limit the amount of posts which are retrieved or to even limit what's retrieved inside of the posts but that adds more complexity to the api and often you will end up fetching more data than you're interested in if your client app only wants to output an overview of all the posts and for that it might only need the id the image and the title there is no need to also fetch the description the excerpt the creator id and so on and still all of that might be fetched or typically will be fetched with a rest api so fetching too much is a common problem with rest apis a huge advantage of the rest api also to make that clear though is that it's pretty clear pretty easy to understand typically it's pretty clear that if you send a get request to slash posts you get back all data but i'd argue that this is also quite understandable and the advantage of graphql can be that you can be very specific about which kind of data you want to retrieve you want to get the user data here but only name and age so whilst for the user our information might also be stored in the database let's say the id and the hobbies here for this query we're not fetching it so graphql queries allow you to be more specific regarding which data you want to fetch and that can reduce the amount of data which is transferred over the wire now with that it to me sounds a bit like draftql apis are always better than rest apis and to be honest it's hard to really compare them or to really make that argument they're definitely popular and the advantages are absolutely there i personally think that graphql apis bring many advantages to the table but rest apis are definitely way more common these days it's also this clarity this easy mapping to certain endpoints which makes using them a bit easier you also don't have to learn a new query language and when you write the client-side code you don't have to use any special packages which you often have to use with graphql apis to write proper queries and have easily manageable code on the client client-side code can get cluttered if you're working with a graphql api and you're using it incorrectly or without a specific package and you start writing all these queries manually it also might be error prone sending requests to certain endpoints is definitely easier there i would argue also when you are the one writing or creating such an api building rest apis tends to bit a bit easier than building graphql apis all that is only true though if we don't really consider third-party packages which help us with that with such packages and services like the apollo package for example it's definitely easy to build and use graphql apis and therefore as always it comes down to your personal preferences to your experience and also to what you're trying to achieve if you're building a web application that needs to query different kinds of data on different pages and bandwidth really needs to be conserved and you want to make sure you can be very specific regarding the data you're retrieving a graphql api might be much better if your application works differently and you typically want a lot of data per page of your app a rest api might be great because the potential disadvantage of fetching too much data might not really be a disadvantage for you so hopefully this video was helpful hopefully you now have a solid understanding of how rest apis and graphql apis differ when you might want to use which and what they also have in common and i'd love to see you in other videos as well if you like this one of course check out the videos the rest api sirius the graphql api series and my complete node course which i already mentioned in the video if you haven't done so already subscribe the channel like the video if you liked it and hopefully see you in future videos too bye

Channel: Academind

Views: 246,314

Rating: 4.9169664 out of 5

Keywords: rest, rest api, graphql, graphql api, rest vs graphql, node, node.js, rest api nodejs, rest nodejs

Id: PeAOEAmR0D0

Length: 17min 41sec (1061 seconds)

Published: Wed Sep 04 2019