REST vs GraphQL – What’s the best kind of API?

00:00:00 when you're working with web apis in web
00:00:03 development you typically have the
00:00:04 choice between rest apis and graphql
00:00:07 apis
00:00:07 at least if you're the one building the
00:00:09 api you can choose which kind of api you
00:00:11 want to build
00:00:12 now there are some misconceptions
00:00:15 regarding these apis for example people
00:00:17 thinking that graphql apis can only be
00:00:20 used with react frontends which is not
00:00:22 the case
00:00:22 and therefore in this video we'll have a
00:00:24 look at the differences between these
00:00:26 two
00:00:26 api approaches we'll also have a look at
00:00:29 what they have in common
00:00:31 and therefore hopefully by the end of
00:00:32 the video you have a better
00:00:33 understanding of
00:00:34 what the concepts behind the two apis
00:00:37 are and when you might want to work with
00:00:39 which
00:00:43 so what's the idea behind rest apis and
00:00:47 graphql
00:00:47 apis well in general when i talk about
00:00:50 apis here
00:00:51 and therefore i of course mean apis that
00:00:54 we expose
00:00:55 on some servers so in the end a web api
00:00:59 to which you can send http requests from
00:01:01 some client be that a web page
00:01:03 or a mobile app then that means that we
00:01:06 have a web service which
00:01:08 exposes certain entry points you could
00:01:11 say
00:01:12 where clients as i said web apps mobile
00:01:15 apps
00:01:16 can fetch data or send data to and
00:01:19 for building such a web service you
00:01:21 typically follow one of these two
00:01:22 approaches
00:01:23 you either build such a rest api and use
00:01:26 the concepts related to that
00:01:28 or you follow that graphql api approach
00:01:30 and build your web service in that way
00:01:32 in both cases in both scenarios you have
00:01:35 a web service
00:01:36 but how you build your web service also
00:01:38 influences
00:01:39 how the client queries that service or
00:01:42 uses that service so which code needs to
00:01:44 be written in the client app
00:01:46 but back to rest api versus graphql api
00:01:49 a rest api embraces the concept of
00:01:52 having multiple
00:01:53 endpoints which means multiple urls
00:01:57 are exposed by your web service to be
00:01:59 precise
00:02:00 urls or paths on that
00:02:03 domain where you host that web service
00:02:06 that react to different
00:02:08 http methods different http works being
00:02:11 used
00:02:12 in the requests that reach that web
00:02:14 service
00:02:15 now a graphql api on the other hand
00:02:17 works with one
00:02:18 endpoint only which always is reached
00:02:21 with a post request
00:02:23 and you can name it whatever you want
00:02:25 but often it's yourdomain.com
00:02:28 graphql so that's one crucial difference
00:02:30 multiple endpoints versus one endpoint
00:02:33 and i'll dive deeper into this in a
00:02:35 second now in both
00:02:36 apis you typically exchange json data
00:02:40 though i will say that with the rest api
00:02:42 you also might send back binary data you
00:02:45 also can implement something like that
00:02:46 in a graphql api
00:02:48 where you for example also provide a
00:02:50 separate endpoint that returns a file
00:02:53 but typically json data is exchanged so
00:02:56 that's pretty much the same
00:02:58 also the same is that you can use any
00:03:00 server-side language and framework and
00:03:02 also any front-end language and
00:03:04 framework
00:03:05 when working with a rest api and also
00:03:07 when working with a graphql api
00:03:09 so you can build that api on a server on
00:03:12 the backend with any programming
00:03:14 language you want with php with node
00:03:16 with java with python that really
00:03:18 doesn't matter
00:03:19 you can use any language you want and on
00:03:21 the front end you can also use any
00:03:23 technology you want

00:03:24 you can be building a mobile app with
00:03:26 swift you might be building a web app
00:03:28 with angular or react
00:03:30 that does not matter and i'm emphasizing
00:03:32 this because a common misconception with
00:03:34 graphql
00:03:36 since it was invented by facebook is
00:03:38 that you have to use
00:03:39 react in order to communicate with a
00:03:41 graphql api
00:03:43 and that's just not correct any front
00:03:46 end can be used because in the end it's
00:03:48 just about sending
00:03:49 the right http requests to the web
00:03:51 service
00:03:53 also common for both apis is that
00:03:55 they're stateless
00:03:56 which means they don't care about the
00:03:58 exact client to them
00:04:00 for example you don't see session based
00:04:02 authentication approaches being used
00:04:04 there
00:04:04 because you don't store any data about
00:04:07 the client
00:04:08 on the back end there you just expose
00:04:10 these endpoints
00:04:11 and whoever sends the right kind of
00:04:13 request possibly
00:04:15 combined with some authentication logic
00:04:18 like some attached token
00:04:19 whoever sends a correct request gets the
00:04:22 data or may store some data depending on
00:04:25 what you expose
00:04:26 on your api so that's the rough overview
00:04:29 let's take a closer look
00:04:31 the core difference between these two
00:04:33 kinds of apis really is
00:04:35 how you send requests to them in the
00:04:38 rest api as i mentioned
00:04:40 you work with multiple endpoints that
00:04:42 means multiple
00:04:44 paths multiple urls you could say that
00:04:46 are exposed by your server for example
00:04:49 you could be sending a post request to
00:04:51 yourdomain.com
00:04:53 user and attach some json data which
00:04:56 holds
00:04:57 such a object in the end such a key
00:04:59 value pair with a name and a value for
00:05:01 it of max
00:05:02 that could be a request you send to a
00:05:04 rest api and to that same api you might
00:05:07 also be able to send a get request to
00:05:10 a different path to get all users
00:05:13 so it really is up to the creators of
00:05:15 the api
00:05:16 to decide to which paths for which http
00:05:20 words
00:05:20 you can send which data and these are
00:05:22 the three important pieces that make up
00:05:24 such a request here
00:05:25 you have a http word you have your path
00:05:28 and you have the request
00:05:29 body you might need to attach of course
00:05:32 not all requests
00:05:33 need such a body for example get
00:05:35 requests don't include a body
00:05:37 so that's how you communicate with a
00:05:39 rest api and again
00:05:41 it's the creators of the api that define
00:05:45 which endpoints so which paths for which
00:05:48 http works
00:05:49 are available and if you send the
00:05:51 request to a path or with an http work
00:05:54 that is not supported
00:05:55 you'll get back an error now for a
00:05:58 graphql api as i mentioned
00:06:00 we have one endpoint and that endpoint
00:06:03 can have any path you want often it's
00:06:06 slash
00:06:06 graphql it always takes a post
00:06:10 request though so where a rest api is
00:06:13 flexible and supports get
00:06:14 post patch put delete and so on graphql
00:06:18 apis only work with post
00:06:20 because in a graphql api you don't
00:06:22 target
00:06:23 different endpoints different urls
00:06:26 instead you state what you want in your
00:06:29 request
00:06:30 body and therefore the http work has to
00:06:33 be post
00:06:33 the path is always the same and these
00:06:35 two things are fixed
00:06:37 because it's your request body which
00:06:39 includes
00:06:40 a query language a command which graphql
00:06:43 which the graphql
00:06:45 api on the back end is able to parse
00:06:48 because the graphql

00:06:49 query language which in the end is
00:06:51 encoded in the request body
00:06:53 that is standardized and therefore there
00:06:56 is a common understanding on how it
00:06:57 should be parsed which commands you can
00:06:59 use
00:07:00 and hence the graphql api so the server
00:07:03 is able to parse the incoming request
00:07:05 and understand what you want
00:07:07 almost like how you query a database
00:07:10 with sql or
00:07:11 with mongodb or whichever database
00:07:14 engine and query language you're using
00:07:16 the same logic applies here just always
00:07:18 keep in mind you're not
00:07:20 talking to a database here you're still
00:07:22 talking to a web service
00:07:23 which then just does this parsing for
00:07:26 you and then
00:07:27 the web service so the back backend the
00:07:29 app you wrote on the backend
00:07:31 goes ahead takes that parsed command and
00:07:34 does whatever you define on the backend
00:07:36 that again is really up to you
00:07:38 as the developer of the backend to
00:07:40 decide what happens
00:07:42 for an incoming query of this type of
00:07:44 that type or
00:07:45 of a totally different type so let's
00:07:48 zoom in a bit and let's start with the
00:07:50 rest api
00:07:51 there you learned it's all about client
00:07:53 server communication
00:07:54 and on that server you can do whatever
00:07:57 you want work with
00:07:58 files reach out to a database run some
00:08:01 complex logic which you can't or don't
00:08:03 want to run in the client app
00:08:05 and so on and just to emphasize this
00:08:06 again client could be a web app could be
00:08:08 a mobile app
00:08:09 server is well your server using any
00:08:12 server side language you want
00:08:13 now from the client you can send
00:08:15 requests to the server
00:08:17 and such a request has to be structured
00:08:20 with a certain path
00:08:21 with a certain http word and possibly
00:08:24 then also some body that needs to be
00:08:26 attached to some of the requests like
00:08:28 for example to post requests
00:08:30 but you're not limited to post requests
00:08:32 you can send
00:08:33 get requests patch requests and so on
00:08:35 and also to different
00:08:37 endpoints all the endpoints that can
00:08:39 hold dynamic
00:08:40 segments which you then parse on the
00:08:42 server to find out
00:08:44 what the user wants which resource
00:08:46 should be retrieved
00:08:47 so you could say that in a rest api your
00:08:50 api
00:08:51 endpoints in the end map resources map
00:08:55 actions that happen on the server for
00:08:57 example the
00:08:58 action to get all posts or to create a
00:09:01 new post
00:09:02 to certain url http word
00:09:06 combinations
00:09:08 and as i mentioned it's more than just
00:09:10 get and post on a rest api
00:09:13 you really have support for get post put
00:09:16 patch also delete and also
00:09:19 other http words like options which is
00:09:23 rarely one you directly use though
00:09:24 instead that's typically automatically
00:09:26 sent by the client
00:09:27 and not really important here of course
00:09:30 i do have a complete series here on this
00:09:32 channel where i
00:09:34 build a rest api from scratch with you
00:09:36 with nodejs
00:09:37 and i can only recommend that you check
00:09:39 out this series to learn more about it
00:09:41 and get a feeling for how you build such
00:09:43 an api how it works how you reach out to
00:09:45 a database there
00:09:46 and much more so what about graphql
00:09:49 there
00:09:50 well unsurprisingly hopefully we have
00:09:52 the
00:09:53 same base setup client and server
00:09:56 which want to talk to each other server
00:09:58 is responsible for any server side logic
00:10:00 database access and so on
00:10:02 i also have a video why clients don't
00:10:04 directly talk to databases by the way
00:10:06 that might be interesting to you as well
00:10:08 all these extra resources

00:10:10 are of course linked in the video
00:10:11 description and now if we come back to
00:10:13 the graphql api the question is how do
00:10:15 we send the request there
00:10:17 now as i said you don't have multiple
00:10:19 endpoints instead you have one endpoint
00:10:21 which always takes a post request
00:10:23 because that one request which you send
00:10:26 is not targeting specific actions on the
00:10:29 server by the combination of
00:10:30 url and http word instead
00:10:34 it's the query expression that's part of
00:10:37 the request
00:10:38 data so of the request body which is
00:10:40 then parsed by the server
00:10:42 so that the server is then able to do
00:10:44 something to retrieve the data you need
00:10:46 a graphql query so such a query
00:10:48 expression which you might include in
00:10:50 the
00:10:51 request body typically looks like this
00:10:54 and i also have a complete series on
00:10:57 this channel where we build a graphql
00:10:59 api
00:11:00 from scratch just as with the rest api
00:11:02 so also check out this graphql api
00:11:04 series
00:11:05 if you want to learn more about that
00:11:07 also check out my node.js complete guide
00:11:09 course
00:11:10 there i dive into both in one course and
00:11:12 of course not just into that but into
00:11:14 node.js and express and all of that
00:11:16 from scratch so that might also be worth
00:11:18 a look
00:11:20 back to the query such a graphql query
00:11:23 is typically made up of an operation
00:11:25 type which you specify there you have
00:11:28 three important types
00:11:29 query which means you want to query for
00:11:31 some data you want to get some data
00:11:33 but you also have mutation and
00:11:34 subscription which means
00:11:36 with mutation you want to edit some data
00:11:39 you want to
00:11:40 store new data or added existing data on
00:11:43 the server
00:11:43 with a subscription you want to set up a
00:11:45 live subscription so that the server
00:11:48 actively informs you about changes that
00:11:50 happened there
00:11:51 now this will not be possible over the
00:11:53 normal http protocol
00:11:55 for that you will need websockets
00:11:56 instead now back to that query
00:11:59 we know the operation type now then you
00:12:03 give that operation
00:12:04 an identifier you could say you could
00:12:06 say an endpoint
00:12:07 this is important for the server to
00:12:09 understand with which resource you want
00:12:12 to work and of course you can't send any
00:12:14 arbitrary queries let me really make
00:12:16 that clear
00:12:17 as you learn in my graphql from scratch
00:12:19 series you'll see that on the server
00:12:21 you of course parse that incoming query
00:12:23 but then you
00:12:25 only support a couple of endpoints or a
00:12:27 couple of
00:12:28 resources that can be targeted you don't
00:12:31 want to make
00:12:32 everything mutatable or you don't want
00:12:34 to allow the client to query for any
00:12:36 kind of data
00:12:37 you on the server when you define the
00:12:40 graphql api when you write the code
00:12:42 there
00:12:42 you don't just parse the incoming query
00:12:45 you also then define what you do with
00:12:46 the parsed result
00:12:48 and which kind of queries you want to
00:12:49 support so to say
00:12:51 well last but not least if we go back to
00:12:53 the query we know
00:12:54 what we want to do query data or mutate
00:12:57 data which kind of data we'd like to get
00:13:00 or mutate and then for that specific
00:13:03 data we
00:13:04 also specify which fields we want to
00:13:07 work on so which
00:13:08 fields we want to get back for example
00:13:10 and that's one of the huge advantages
00:13:12 of graphql compared to rest apis
00:13:16 with rest apis you target a specific
00:13:18 resource
00:13:19 for example get posts and you retrieve
00:13:23 all posts with all fields that belong to
00:13:26 a post
00:13:27 so with the id the title the description

00:13:30 and so on
00:13:31 you might use query parameters to
00:13:34 implement something like pagination to
00:13:36 limit the amount of posts which are
00:13:37 retrieved or
00:13:38 to even limit what's retrieved inside of
00:13:40 the posts
00:13:41 but that adds more complexity to the api
00:13:44 and often you will end up fetching more
00:13:46 data than you're interested in
00:13:48 if your client app only wants to output
00:13:51 an
00:13:51 overview of all the posts and for that
00:13:53 it might only need the id the image and
00:13:55 the title
00:13:56 there is no need to also fetch the
00:13:58 description the
00:13:59 excerpt the creator id and so on and
00:14:02 still
00:14:03 all of that might be fetched or
00:14:05 typically will be fetched with a rest
00:14:07 api so fetching too much
00:14:09 is a common problem with rest apis
00:14:12 a huge advantage of the rest api also to
00:14:15 make that clear though
00:14:16 is that it's pretty clear pretty easy to
00:14:18 understand typically it's pretty clear
00:14:20 that if you send a get request
00:14:22 to slash posts you get back all data
00:14:25 but i'd argue that this is also quite
00:14:27 understandable
00:14:28 and the advantage of graphql can be that
00:14:32 you can be very specific about which
00:14:33 kind of data you want to retrieve
00:14:35 you want to get the user data here but
00:14:37 only name and age
00:14:38 so whilst for the user our information
00:14:40 might also be stored in the database
00:14:42 let's say the id and the hobbies here
00:14:45 for this query we're not fetching it
00:14:47 so graphql queries allow you to be more
00:14:49 specific
00:14:50 regarding which data you want to fetch
00:14:53 and that can reduce the amount of data
00:14:54 which is transferred over the wire
00:14:57 now with that it to me sounds a bit like
00:15:00 draftql apis are always better than rest
00:15:03 apis
00:15:04 and to be honest it's hard to really
00:15:06 compare them or to really make that
00:15:08 argument
00:15:09 they're definitely popular and the
00:15:10 advantages are absolutely there
00:15:13 i personally think that graphql apis
00:15:16 bring many advantages to the table
00:15:19 but rest apis are definitely way more
00:15:22 common
00:15:22 these days it's also this clarity this
00:15:25 easy mapping
00:15:26 to certain endpoints which makes using
00:15:29 them a bit easier
00:15:30 you also don't have to learn a new query
00:15:33 language and when you write the
00:15:34 client-side code
00:15:36 you don't have to use any special
00:15:38 packages which you
00:15:39 often have to use with graphql apis
00:15:42 to write proper queries and have easily
00:15:45 manageable code on the client
00:15:47 client-side code can get cluttered if
00:15:49 you're working with a graphql api
00:15:51 and you're using it incorrectly or
00:15:53 without a specific package and you start
00:15:56 writing all these queries manually
00:15:57 it also might be error prone sending
00:16:00 requests to certain endpoints is
00:16:02 definitely easier there
00:16:03 i would argue also when you are the one
00:16:06 writing or creating such an api
00:16:08 building rest apis tends to bit a bit
00:16:10 easier than building graphql apis
00:16:13 all that is only true though if we don't
00:16:16 really consider
00:16:17 third-party packages which help us with
00:16:19 that
00:16:20 with such packages and services like the
00:16:23 apollo package for example
00:16:25 it's definitely easy to build and use
00:16:28 graphql apis
00:16:29 and therefore as always it comes down to
00:16:31 your personal preferences to your
00:16:33 experience
00:16:34 and also to what you're trying to
00:16:36 achieve if you're building a web
00:16:38 application that needs to query
00:16:41 different kinds of data on different
00:16:42 pages and
00:16:44 bandwidth really needs to be conserved
00:16:47 and you want to make sure
00:16:48 you can be very specific regarding the

00:16:50 data you're retrieving
00:16:52 a graphql api might be much better if
00:16:55 your application works differently
00:16:57 and you typically want a lot of data per
00:16:59 page of your app
00:17:00 a rest api might be great because the
00:17:03 potential disadvantage of fetching too
00:17:05 much data
00:17:06 might not really be a disadvantage for
00:17:08 you
00:17:09 so hopefully this video was helpful
00:17:11 hopefully you now have a solid
00:17:13 understanding of
00:17:14 how rest apis and graphql apis differ
00:17:18 when you might want to use which and
00:17:20 what they also have in common
00:17:21 and i'd love to see you in other videos
00:17:23 as well if you like this one of course
00:17:25 check out the videos the rest api sirius
00:17:27 the graphql api
00:17:29 series and my complete node course which
00:17:31 i already mentioned in the video
00:17:33 if you haven't done so already subscribe
00:17:35 the channel like the video if you liked
00:17:37 it
00:17:37 and hopefully see you in future videos
00:17:39 too bye

You may also like