REST API (Work In Progress)

Source: Dev.to

In our last episode, we explored the networking protocols that make data flow across the web, like TCP for reliability, HTTP/HTTPS for requests, and WebSockets for real‑time chats. Building on that, Episode 3 dives into how applications communicate in more structured ways, starting with APIs. We’ll focus on REST APIs first, using everyday analogies to keep it simple. This sets the stage for later topics in the series, like gRPC, GraphQL, and communication patterns.
Let’s get into it with the basics of app architectures and how REST fits in.

The Evolution of Tiers (The Restaurant Analogy)

To explain how apps are built, think of it like running a restaurant. We’ll use this digital kitchen idea to break down the three main architectures.

1‑Tier Architecture: The Food Truck

Everything happens in one spot. The guy taking your order is also cooking and pulling stuff from the fridge.

In software, this means the user interface, business logic, and data storage are all on the same machine—just like an old desktop app.

Problem: If a crowd suddenly shows up, the whole thing slows down or crashes. You can’t easily add help without starting over.

2‑Tier Architecture: The Small Diner

The operation is split into two distinct spaces:

• Front counter – customers place orders and interact with staff.
• Back kitchen – the actual work happens.

The cashier focuses on talking to customers, taking orders, maybe doing light checks like “is this a valid order,” while the kitchen handles cooking, pricing rules, checking ingredients, and pulling items from the fridge.

In software terms:

• Client – handles the user interface and basic validation.
• Server – contains both the business logic and the database.

Advantages: Handles far more customers than a food truck because multiple clients can talk to the same kitchen at once, and changes to the kitchen don’t necessarily require rebuilding the counter.
Drawbacks: The kitchen becomes responsible for everything beyond taking the order. As the menu grows and customers want more custom options, all those special rules pile up in the kitchen, making it harder to manage and slower to respond. Scaling storage or logic requires redesigning the whole kitchen because the logic and data live together.

3‑Tier Architecture: The Fine‑Dining Restaurant

Now the restaurant is fully professional and built to scale.

• Presentation layer (front‑of‑house staff) – focuses only on the guest experience, guiding customers through the menu and taking orders without knowing how the food is prepared.
• Application layer (kitchen chefs) – concentrates purely on cooking and applying business rules, independent of how the order was taken.
• Data layer (storage area) – manages ingredients, recipes, and inventory on its own, isolated from the dining room and kitchen.

In software, this separation means each tier has a single responsibility, allowing you to add more waiters, chefs, or a bigger warehouse without redesigning the entire system. It makes handling growth, changing menus, or supporting huge traffic spikes far easier.

What is an API? What is REST?

Before we talk REST, let’s define API (Application Programming Interface). In the restaurant, it’s like the order slip the waiter hands to the chef. The frontend (waiter) writes what’s needed and passes it to the backend (chef). The waiter doesn’t need to know how the oven works; they just follow the format. It’s a simple contract between systems, letting them talk without knowing each other’s insides.

REST (Representational State Transfer) is a style for building APIs. If an API is the order slip, REST is the standard way to fill it out, so everyone uses the same language.

Instead of random notes, REST uses consistent nouns and verbs over HTTP (from Episode 2).

• Nouns (Resources): Things like /orders, /menu-items, /customers—the stuff you’re dea (text truncated in original).

Verbs (Methods)

• GET – fetch something
• POST – create new
• PUT – update
• DELETE – remove

This makes the 3‑tier setup work smoothly over the internet, letting frontends talk to backends easily. For prasunchakra.com, if it had a backend API, you might GET /posts to fetch blog data.