Client-Server API Communication: Mastering REST (Part 1)

Hey there! If you're dipping your toes into web or mobile development, you've likely heard that getting the client and server to talk smoothly is everything. The speaker behind this video series? They call it the single most important topic — and for good reason. It pops up in every interview, whether you're a frontend wizard, a mobile dev, or just someone building cool apps.

There’s so much to unpack that it’s split into three parts. This first one? We’re tackling the heart of the problem: how clients and servers communicate, with a spotlight on the undisputed champ — REST. Think of this as us grabbing coffee and walking through it together — no jargon overload, just clear, memorable insights.

Types of Communication: Who’s Actually Using Your API?

Before we geek out on protocols, let’s answer a simple but critical question:
Who’s on the other side of your API?

That splits communication into two worlds:

1. Client-to-Server Communication

• Who? Your browser, a Progressive Web App (PWA), or a mobile app.

• Reality check: Humans are involved — users, testers, devs inspecting responses in DevTools.

• Priority? Readability and usability often beat raw performance.
  JSON that’s easy to read > saving 2ms if it confuses everyone.

2. Service-to-Service Communication

• Who? Backend services talking to each other.

• Better term: “Service,” not “server.” One machine can run many services; they can live anywhere in the cloud.

• Key difference: No human in the loop. It’s machine-to-machine.

• Priority? Efficiency, speed, reliability — every millisecond and byte counts.

Bottom line: Client APIs should be friendly. Service APIs should be fast.

API Scope: Private or Public?

Another big one:
Is your API just for your team (private/first-party), or open to the world (public/third-party)?

We’re laser-focused on client-server here, but we’ll hint at what works best depending on scope.

Protocols: So Many Choices — How to Stand Out in Interviews

You’ve got a toolbox:
REST, GraphQL, gRPC, tRPC, WebSockets, and more.

In interviews? REST is the default. Most candidates jump straight into fetch() or Axios.
Don’t do that.

Your goal:
Show you know the alternatives, their pros and cons, and — most importantly — why you’d choose one.
Always say:

“I’d pick REST because… but I know GraphQL would solve X better, and here’s how I’d decide.”

Bonus: “REST” is misused everywhere. Most “REST APIs” aren’t truly RESTful. Call it out (politely) — you’ll look sharp.

What We’ll Cover (and What We Won’t)

In this series:

1. Four core protocols/patterns: REST, GraphQL, gRPC, tRPC

2. Real-world examples

3. Interview-winning tips

Skipping for now:

• SOAP → Ancient, rarely used. Think floppy disks.

• WebSockets → Amazing for real-time (chat, live updates), but saved for later.

REST: What It Actually Means (Not Just “JSON over HTTP”)

REST = Representational State Transfer
It’s not a tool or protocol — it’s an architectural style for networked apps.

Invented by Roy Fielding in his 2000 PhD dissertation.
True REST follows six guiding principles. Most devs have never heard of them — so their APIs are “REST-ish” at best.

Let’s go through them like a story.

1. Uniform Interface: Consistency Is King

This is the soul of REST. It has three pillars:

• Resource Identification
  Use URIs: /users/123, /posts/456 — never /getUser?id=123

• Self-Descriptive Messages
  Every response says what it is:
  Content-Type: application/json

• HATEOAS (Hypermedia as the Engine of Application State)
  Responses include links to what you can do next.

The dream? An API so discoverable, you don’t need docs. Just follow the links.

Blog Platform Example:

GET /users/ahmed
→ { "name": "Ahmed", "links": { "articles": "/users/ahmed/articles" } }

GET /users/ahmed/articles
→ [ { "title": "My Post", "links": { "comments": "/posts/1/comments" } } ]

GET /posts/1/comments
→ [ ... ]

No Swagger. No Postman. Just follow the yellow brick hyperlinks.

2. Statelessness: The Server Has Amnesia

Every request is complete. The server remembers nothing between calls.

“Who are you again?”

But What About Login Sessions?

Myth: Sessions break statelessness.
Truth: Only if the server stores the session.

Stateless = scalable. No “sticky sessions” on load balancers. Pure bliss.

3. Cacheability: Don’t Make Me Ask Twice

Use headers like Cache-Control to say:

“This response is fresh for 5 minutes.”

Browsers, CDNs, proxies — they all cache.
Result? Lightning-fast repeats.

4. Client-Server Separation: You Do You

• Client → UI, UX, presentation

• Server → Data, logic, storage

Reuse the same API for web, iOS, Android. Scale independently. Win-win.

5. Layered System: Magic Behind the Curtain

Your client talks to “the server” — but there might be:

• Load balancers

• Reverse proxies

• Security gateways

• CDNs

Client doesn’t care. Just works.

6. Code on Demand (Optional)

Server sends executable code (like JavaScript) to extend the client.
Think: dynamic widgets.
Rarely used, but allowed.

REST vs. “RESTful” APIs

Most are not RESTful. They’re HTTP APIs.
Some devs jokingly call them “Rest-foolish” 😄

Why We Still Love REST

As a Pattern:

• Works over any protocol (HTTP is just popular)

• Web-native

• Low coupling — client and server evolve separately

As HTTP + JSON:

• Simple — everyone knows it

• Browser support — fetch(), caching, CORS

• Human-readable JSON → easy debugging

• Tooling paradise — Postman, Swagger, curl

• Caching built-in

The Ugly Truth: REST’s Pain Points

It’s 25 years old. The web has changed.

1. Over-fetching

“I just want the user’s name and avatar… why did you send me their entire life story?”

Wastes bandwidth, slows mobile.

Fixes:

• ?fields=name,avatar (sparse fieldsets)

• New lightweight endpoints

• ?summary=true

• Or… just use GraphQL

2. Under-fetching

“I need an article + comments + author bios… that’s 3 round-trips.”

Latency adds up fast.

Fixes:

• Bundle data (risks over-fetching)

• Add new endpoints

• Or… just use GraphQL

3. Versioning Nightmare

APIs evolve. Old apps don’t.

Like telling a 5-year-old:
“The new robot sings! But your little brother still has the old one that doesn’t. Now you need two robots — and both must work!”

Solution: /api/v1/, /api/v2/ → maintenance hell.

4. Endpoint Explosion

Too many URLs for complex operations.

5. CRUD-Only Vibes

Hard to model complex actions cleanly.

6. No Schema

Clients can’t auto-validate or type-check responses.

When to Use REST (and When to Run)

✅ Use REST when:

• Building a public API (devs expect it)

• Simple CRUD app

• Low complexity

• You want maximum compatibility

❌ Avoid REST when:

• Over/under-fetching is killing performance → GraphQL

• Data shape is complex or dynamic → GraphQL

• Service-to-service (microservices) → gRPC

• Performance is critical → gRPC, tRPC, or message queues

REST is the Swiss Army knife — reliable, familiar, but not always the best tool.

Wrapping Up: You’ve Got This

REST isn’t going anywhere. It’s foundational.
But now you see through the buzzword:

• You know the 6 principles

• You can spot a fake REST API

• You can justify your choice in an interview

• You know when to switch

Next up: GraphQL and RPC deep dives.
Practice explaining why — not just how.
You’re not just coding APIs anymore.
You’re designing systems.