Before we jump to business - a quick reminder! We’re approaching October—that time of year in India when the cool breeze begins to hit your head, and you find yourself undecided whether to switch the fan on or off. It's also the time when festivities begin, you start planning for the year ahead.
Haha! Enough romanticisation 🤪 A lot of you reached out to me saying that you loved the last blog on authentication vs authorisation.
And then we all heard that a random person on the internet was able to access sensitive data about DotPe (a company in the contactless dining space) and its restaurant clients.
This included information like how many active customers DotPe has and the sales each restaurant makes on DotPe. The reason? DotPe hadn't secured their APIs with authentication, allowing unrestricted access.
What better live case study could there be for product managers to understand the business impact of authentication and authorization than this incident?
Alright, let’s get down to business and chat about —GraphQL vs. REST APIs.
If you’ve ever been in a room with developers, you've probably heard the debate: “GraphQL is the future,” “REST is more stable,” “GraphQL gives clients flexibility,” “REST is simpler,” etc. But what really separates these two? Let me break it down for you in a way that’ll make you sound like the smartest person in the room (or at least the Zoom meeting!).
REST vs. GraphQL: Let’s Start with the Basics
Imagine you’re at a restaurant (because I’m always thinking about food, Rajma Chawal to be precise!).
With REST, it's like you get a full set menu. You can only order what’s on it, no substitutions. Want just the dessert? Tough luck, you’re getting the whole meal. Want the salad without dressing? Nope, you’re stuck with it.
GraphQL, on the other hand, is like ordering à la carte. You tell the waiter exactly what you want, and they bring only that. Salad? Sure. Dessert? Of course. And nothing extra you didn’t ask for.
This is the core difference between REST and GraphQL: REST gives you everything in a pre-defined format, while GraphQL lets you ask for exactly what you need.
Btw, before you scroll ahead! Let me have your attention - I am starting Tech For Product Manager cohort starting 13th October - https://www.xplainerr.com/cohorts/tech-for-product-managers. Do check it out, if you want to crack tech rounds of PM Interview with ease! (10% off for you. Use code: XPHP)
REST API 🍽️
REST (Representational State Transfer) is simple. A rule for building APIs.
It has been the backbone of web services for ages. It’s simple, reliable, and easy to use.
Here’s how REST works:
URL for Every Resource: With REST, you usually have a URL for each resource (e.g.,
/users
,/orders
). It’s like going to different pages in a book for each topic.Fixed Responses: REST APIs give you a fixed structure in their response. So if you request information about a user, you might get the entire profile—name, email, address—even if all you wanted was the email.
Statelessness: Each request is independent. The server doesn’t remember your previous requests, so every call must contain all the necessary data.
Example:
You call GET /users/123
and REST might return:
json
{ "id": 123,
"name": "John Doe",
"email": "john@example.com",
"address": { "city": "San Francisco", "state": "CA" }
}
Even if you just wanted the email, you get the whole response.
GraphQL API 🧑🍳
GraphQL (developed by Facebook in 2012) is a bit newer, and people love it for the flexibility it provides.
Here’s how GraphQL works:
Single Endpoint: With GraphQL, there's just one endpoint (usually
/graphql
). It’s like ordering everything from the same waiter instead of going to different food stations.Tailored Responses: You specify what data you need in your query, and the server responds with exactly that—no more, no less.
Example:
You ask for just the email in GraphQL like this:
graphql
{ user(id: 123) { email } }
And voilà! You only get only email address: john@example.com
json
{ "data":
{ "user":
{ "email": "john@example.com" }
} }
No unnecessary baggage! 🎒
Key Differences 🔑
Flexibility
GraphQL: Lets you request exactly the data you need.
REST: Gives you fixed responses based on the resource you’re querying.
Endpoints
GraphQL: One endpoint for everything (
/graphql
).REST: Multiple endpoints based on the resource (
/users
,/orders
, etc.).
Over-fetching vs. Under-fetching
REST: You might get too much data (over-fetching) or too little, forcing extra requests (under-fetching).
GraphQL: You always get just the right amount of data because you control the query.
Versioning
REST: Needs versioning (
/v1/users
,/v2/users
) to handle changes.GraphQL: No need for versioning—you query what you need, regardless of changes to the schema.
So, Which Should You Use? 🤔
It depends on your use case!
REST is great if you need a simple, reliable solution that doesn’t require complex querying. It's been around longer, so it has strong support and documentation.
GraphQL is perfect for flexible, dynamic applications where you want to minimize data transfer, especially in mobile apps or systems with limited bandwidth.
Both have their strengths, and neither is going away anytime soon.
In a Nutshell 🥜
REST: Like a set menu—reliable but not flexible.
GraphQL: Like à la carte dining—tailored to your needs with ultimate flexibility.
And that’s it for today’s newsletter! Now you’ve got the lowdown on REST vs. GraphQL, and you’ll sound like a pro the next time it comes up in conversation (or interviews!).
Until next time—keep learning and stay curious. Also, last reminder 😉 Do check my Tech For Product Manager cohort - https://www.xplainerr.com/cohorts/tech-for-product-managers