REST vs GraphQL: Talkative vs Reserved
Key Points
- The speaker uses an analogy of two coworkers—talkative “R” (REST) and concise “G” (GraphQL)—to illustrate that REST returns all data by default while GraphQL lets clients request exactly what they need.
- Both REST and GraphQL are approaches to building APIs, which enable different applications (like web or mobile clients) to communicate with servers over the internet.
- In GraphQL, a **schema** defines the full data model, **queries** fetch data matching that schema, **resolvers** retrieve and assemble the requested data (potentially from multiple sources), and **mutations** handle create, update, and delete operations.
- REST is an architectural style centered on **resources**, each identified by a unique URI, and uses standard HTTP methods (GET, POST, PUT, DELETE) to perform CRUD actions on those resources.
- The key trade‑off is that REST may deliver excess data requiring client‑side filtering, whereas GraphQL offers precise, single‑request data retrieval, reducing over‑fetching and under‑fetching.
Sections
- Untitled Section
- REST vs GraphQL Overview - The passage explains REST’s core concepts—URI‑identified resources accessed via HTTP methods and returned as JSON or XML—then compares REST to GraphQL, noting that both build APIs over HTTP using JSON but differ in that REST uses multiple resource endpoints with full responses, whereas GraphQL employs a single endpoint allowing clients to request precisely the data they need.
- Encouraging Viewer Interaction - The speaker invites viewers to ask questions, like the video, subscribe for future content, and thanks them for watching.
Full Transcript
# REST vs GraphQL: Talkative vs Reserved **Source:** [https://www.youtube.com/watch?v=PTfZcN20fro](https://www.youtube.com/watch?v=PTfZcN20fro) **Duration:** 00:07:26 ## Summary - The speaker uses an analogy of two coworkers—talkative “R” (REST) and concise “G” (GraphQL)—to illustrate that REST returns all data by default while GraphQL lets clients request exactly what they need. - Both REST and GraphQL are approaches to building APIs, which enable different applications (like web or mobile clients) to communicate with servers over the internet. - In GraphQL, a **schema** defines the full data model, **queries** fetch data matching that schema, **resolvers** retrieve and assemble the requested data (potentially from multiple sources), and **mutations** handle create, update, and delete operations. - REST is an architectural style centered on **resources**, each identified by a unique URI, and uses standard HTTP methods (GET, POST, PUT, DELETE) to perform CRUD actions on those resources. - The key trade‑off is that REST may deliver excess data requiring client‑side filtering, whereas GraphQL offers precise, single‑request data retrieval, reducing over‑fetching and under‑fetching. ## Sections - [00:00:00](https://www.youtube.com/watch?v=PTfZcN20fro&t=0s) **Untitled Section** - - [00:03:12](https://www.youtube.com/watch?v=PTfZcN20fro&t=192s) **REST vs GraphQL Overview** - The passage explains REST’s core concepts—URI‑identified resources accessed via HTTP methods and returned as JSON or XML—then compares REST to GraphQL, noting that both build APIs over HTTP using JSON but differ in that REST uses multiple resource endpoints with full responses, whereas GraphQL employs a single endpoint allowing clients to request precisely the data they need. - [00:07:16](https://www.youtube.com/watch?v=PTfZcN20fro&t=436s) **Encouraging Viewer Interaction** - The speaker invites viewers to ask questions, like the video, subscribe for future content, and thanks them for watching. ## Full Transcript
So I have these two colleagues. Let's
call them R.
And then we'll call the other one G.
Just using initials here to to protect
their identities. Now R is rather
talkative. They tell you everything they
know whether you want to hear it or not.
G on the other hand is much more
reserved. They share the information
that's absolutely necessary but no more.
But they're always willing to share more
if I do ask. And look, this is one way
that we can think of the differences
between REST, that's the R, and GraphQL,
that's the G. Rest can be a bit of a
know-it-all. You have to be specific in
your requests and sift through all the
data that's returned. With GraphQL, you
can be precise and only retrieve the
data you need. It said that GraphQL
prioritizes giving clients exactly the
data they request and no more. But I'm
I'm getting ahead of myself here. What
clients? What are what are these
technologies do? Well, both REST and
GraphQL are used to build something
called APIs
or application programming interfaces.
And those allow different applications
to communicate with each other over the
internet. So an API takes requests from
a from a client over here and that
client can be like a web application or
a mobile app or something like that and
then it retrieves the necessary data
from a server over here. Now REST or
representational state transfer and
graph query language are two different
approaches to building APIs that have
their own strengths and weaknesses. So,
REST is an architectural style that
relies on HTTP requests to interact with
resources while GraphQL is a query
language that allows clients to retrieve
data from multiple data sources in a
single API call. So, let's define some
terminology and we're going to start
with GraphQL.
So in GraphQL we have something called
a schema and this is the blueprint that
defines all the possible data that
clients can query through a service. Did
I say query? Yeah, query. That's the
next one. So a query is a request for
data that follows the structure defined
in the schema. Then we have something
called a resolver.
And the resolver is called to retrieve
the data that was requested in the
query. And this may involve fetching
data from multiple data sources and
assembling it into a response that
matches the query structure. And then
lastly, we have mutations.
And mutations
their job is to modify data on the
server. So if we think of this in in
terms of the create, read, update, and
delete or the CRUD model, a query that
would be equivalent to the read in a
CRUD. And then all the others, the
create, the update, and the delete,
they're handled by mutations.
So that's GraphQL.
If we take a look at REST, we consider
resources in REST. So resources are
really the fundamental concept in RESTs.
Each resource has a unique identifier
called a URI
that identifies it. So uniform resource
identifier and a client can request a
response using an HTTP method. So the
methods that we can use are get, put,
post and delete. And that gets us access
to those resources. And then the server
responds with a representation of the
resource in a format like JSON or XML.
Now, REST auto allows clients to filter,
sort, and pageionate the data using
query parameters. So, how are GraphQL
and REST similar? Well, both are used
to, as I've mentioned, build APIs that
allow different applications to
communicate with each other over the
internet. both also have a commonality
in that they use frameworks and
libraries
to handle all of the pesky network
details so we don't have to worry about
them and then also both operate over
HTTP although it is worth pointing out
that GraphQL is protocol agnostic also
both can handle requests and responses
using JSON or the JavaScript object
notation
but there are several key differences
between the two technologies that make
them better suited for different use
cases. When requesting data from a
specific endpoint, a REST API returns
the full data set for that resource.
Whereas, in contrast, GraphQL is a query
language specification and set of tools
that allow clients to interact with a
single endpoint. REST APIs often require
multiple requests to fetch related data,
while GraphQL can fetch all the data in
a single request using a complex query
that follows the schema. So clients get
what they request with no overfetching.
Now, REST APIs are already very familiar
to many developers, so people know how
to use them. GraphQL may represent a bit
of a learning curve for some. Rest APIs
are well suited for applications that
require simple CRUD like operations. So
for example, an e-commerce website might
use a REST API to allow customers to
browse products, add items to their
cart, and complete orders. In that case,
the API would use the HTTP methods we
talked about, get put, post, and delete
to manipulate the data like the
products, the orders, and the customer
information. Now on the other hand,
GraphQL is better suited for
applications that require well a bit
more complex
data requests.
And what I mean by that is where we have
examples of many sort of nested fields
or multiple data sources that we need to
pull from. So if we think about a
company that provides a suite of
financial planning tools for its
clients, those tools might require data
from multiple sources. So they might
need to go to bank transactions,
investment portfolios, and credit
scores. And with GraphQL, the company
can build a single API endpoint that
allows clients to query all of the data
in a single request. So clients simply
specify exactly the data that they need
and the server would use a set of
resolvers to fetch the necessary data
from each source and assemble it into a
response that matches the query
structure. Now, REST and GraphQL can
also work together because GraphQL
doesn't dictate a specific application
architecture. It can be introduced on
top of an existing REST API and can work
with existing API management tools. So,
like my work buddies R and G, both REST
and GraphQL have their unique quirks and
strengths. Both have their place in the
world of APIs. And by understanding
their similarities and differences, you
can choose the right tool for the job.
If you have any questions, please drop
us a line below. And if you want to see
more videos like this in the future,
please like and subscribe. Thanks for
watching.