A simple, practical guide to how different API styles actually work - and when to use which.
Every backend uses APIs; but APIs themselves come in many shapes.
After writing two chapters on:
…the final missing piece is understanding how different API styles work, and how they shape your architecture, your frontend, and even your debugging workflow.
This chapter aims to be that map; clean, visual, and beginner-safe.
1. REST, GraphQL, RPC, Serverless & Webhooks - The Simple Definitions
Let’s start with one-sentence clarity.
REST (Representational State Transfer)
A URL represents a resource, and HTTP verbs represent actions.
Analogy: Ordering from a fixed menu.
GraphQL
Ask the server exactly for the data you want.
Analogy: A custom order instead of menu items.
RPC (Remote Procedure Call)
Call server functions as if they were local functions.
Analogy: “Hey server, run this function.”
Serverless / Edge APIs
Tiny functions deployed globally, running only when hit.
Analogy: Having small helpers stationed all around the world.
Webhooks
APIs that call you when something happens.
Analogy: Instead of checking the oven, the oven notifies you when the food is ready.
Clear? Good.
Now we compare them side by side.
2. Side-By-Side Comparison (The Beginner’s Table)
| Feature | REST | GraphQL | RPC (tRPC/gRPC) | Serverless | Webhooks |
|---|---|---|---|---|---|
| How it works | URLs + verbs | One endpoint, query language | Functions over HTTP | Single-purpose functions | Event calls your server |
| Ideal for | CRUD apps | Dashboards, social feeds | Microservices, internal tools | Triggers, tasks, small APIs | Notifications |
| Structure | Resource-based | Query-based | Function-based | File-based | Endpoint-based |
| Learning Curve | Easiest | Medium | Medium | Easy | Easy |
3. How the Same API Looks in Different Styles
Let’s take a simple use case: “Get user by ID”
REST
GET /api/users/12
GraphQL
query {
user(id: 12) {
name
email
}
}
RPC (tRPC style)
user.getById(12)
Serverless (Next.js Route Handler)
export function GET() {
return Response.json({ id: 12, name: "Aryan" });
}
Same goal, different patterns.
REST focuses on resources.
GraphQL focuses on shape.
RPC focuses on functions.
Serverless focuses on events.
Understanding these helps you switch context easily as a full-stack dev.
4. Node vs Express vs Next.js vs Serverless - The Framework Comparison
Beginners often don’t understand why backend code looks different in different tutorials.
Here’s the simplest explanation possible.
Node.js (Native HTTP)
- Lowest-level
- Manual routing
- Manual JSON parsing
- Teaches fundamentals
const http = require("http");
http.createServer((req, res) => {
res.end("Hello");
});
Good for learning.
Not ideal for production.
Express
- Clean routing
- Middleware ecosystem
- Very mature
- Used everywhere
app.get("/users/:id", (req, res) => {
res.json({ id: req.params.id });
});
If REST was a language, Express is the dictionary.
Next.js 16 Route Handlers
- Server by default
- Perfect for React developers
- API collocated with UI
- New boundary rules (RSC vs client)
export async function GET() { ... }
export async function POST() { ... }
Feels modern, predictable, and minimal.
Serverless Functions
- Run only on request
- Stateless
- Auto-scaled
- Perfect for small tasks and integrations
export async function POST() {
// run and exit
}
This is the architecture behind Vercel, Cloudflare, Netlify, etc.
5. When Should You Use Which API Style? (The Practical Guide)
This is the part devs never get a straight answer for.
Here it is.
✔ Use REST when:
- your API needs predictable routes
- you’re building mobile apps
- your team already knows REST
- caching is important
Reality: 80% of web backend is still REST.
✔ Use GraphQL when:
- your frontend needs different shapes of the same data
- you're building social feeds
- dashboards
- nested relational queries
If UI is complex, GraphQL feels magical.
✔ Use RPC when:
- you want type safety
- you’re building internal tools
- you have multiple microservices
- you want “call a function from the server” DX
tRPC is booming for this reason.
✔ Use Serverless when:
- you're handling webhooks
- schedule jobs (CRON)
- upload handlers
- form submissions
- small “one-off” API tasks
Every small startup uses this pattern now.
✔ Use Webhooks when:
- your app needs to react to something that happens in another system
e.g., Stripe payment succeeded → notify your server.
Essential skill for modern SaaS.
6. Real-World Examples (So It Doesn’t Feel Theoretical)
- GitHub → REST
- Shopify → REST + GraphQL
- Stripe → REST + Webhooks
- OpenAI API → REST-style RPC
- Vercel → Serverless
- Notion API → REST
- Discord → REST + WebSockets
You start seeing the patterns everywhere.
7. Which One Should Beginners Learn First?
If you want a simple roadmap:
Start here → REST
The most transferable mental model.
Then → Serverless
Makes backend approachable and cheap.
Then → RPC
If you use React + TypeScript.
Then → GraphQL
When your project really needs it.
Then → Webhooks
When you integrate payments, forms, or external apps.
Most people learn these in the reverse order and get overwhelmed.
Follow this path and you’ll feel far more confident.
8. Final Summary - The Master Map of API Styles
Different APIs aren’t “better” or “worse.”
They’re different tools for different shapes of problems.
REST gives structure.
GraphQL gives flexibility.
RPC gives DX.
Serverless gives scalability.
Webhooks give connectivity.
Once you understand the landscape, switching between them becomes natural.
And that’s what this chapter aimed to do:
give you a clear picture of the entire API universe so you can navigate it confidently as you grow into a full-stack engineer.
Top comments (0)