DEV Community: Prathamesh Dhadbale

How Frontend Talks to Backend — REST, JSON, and CORS Explained Without the Jargon

Prathamesh Dhadbale — Sat, 25 Apr 2026 09:52:43 +0000

You've got a React app on one side. An Express server on the other. And you know you need to connect them somehow.

But then come the questions — what exactly is an API? What makes it "REST"? Why does everyone use JSON? And why does CORS lose its mind the moment you try to fetch something?

Let's answer all of it.

First — what even is an API?

API stands for Application Programming Interface. But forget the full form, here's what it actually means:

Your frontend is a customer. Your backend is a restaurant kitchen. The kitchen doesn't let customers walk in and grab food themselves. Instead there's a menu — a fixed list of things you can order, with specific names and rules.

That menu is your API.

Your backend doesn't expose its database directly to the frontend. Instead it says — "here are the URLs you can call, here's what you send me, here's what I'll send back." The frontend doesn't know or care how the backend stores data internally. It just knows the menu and orders from it.

What makes an API "REST"?

REST is not a library. Not a framework. Not a technology you install.

It's a convention — an agreed-upon style for designing your API so that anyone can understand it without reading a manual.

The core idea is simple:

URLs represent things (called resources) — /jobs, /users, /posts
HTTP methods represent actions on those things

GET    /jobs        → fetch all jobs
POST   /jobs        → create a new job
PUT    /jobs/1      → fully update job with id 1
PATCH  /jobs/1      → partially update job with id 1
DELETE /jobs/1      → delete job with id 1

Notice the difference between PUT and PATCH — PUT means replace the entire resource with new data, PATCH means only update the specific fields you send and leave everything else as it is.

And notice how the URL only describes what you're acting on, not what action you're doing. The HTTP method handles the action. So /getJobs is wrong REST style — it should just be GET /jobs.

That's REST. A clean, readable, predictable way to structure your API.

Status codes — the response's mood indicator

Every response your backend sends comes with a status code — a number that tells the frontend how things went. Think of it as the server's emotional state.

200 OK              → worked perfectly
201 Created         → new resource was created successfully
400 Bad Request     → you sent something wrong
401 Unauthorized    → you're not logged in
403 Forbidden       → you're logged in but not allowed
404 Not Found       → that resource doesn't exist
500 Internal Error  → something broke on the server side

A status code is not the same as your response data. You can send a 200 with wrong data, or a 404 with a helpful error message. Always set both intentionally.

res.status(201).json({ id: 1, company: 'Stripe' }); // created
res.status(404).json({ error: 'Job not found' });    // not found

JSON — why everything uses it

When your frontend sends data to the backend or receives it back, both sides need to agree on a format. That format is JSON.

Here's the thing that trips people up — a JavaScript object and a JSON string look almost identical, but they are completely different things:

// JavaScript object — lives in memory, can have methods
const job = { company: 'Stripe', role: 'Intern' }

// JSON string — plain text, travels over the network
'{"company":"Stripe","role":"Intern"}'

A JavaScript object is a living thing in your computer's memory. JSON is just text — a standardized way of representing that object as a string so it can travel over the network.

The network doesn't understand JavaScript objects. It only carries bytes of text. So before sending, you convert:

JSON.stringify(job)   // object → JSON string (before sending)
JSON.parse(jsonStr)   // JSON string → object (after receiving)

On the frontend with fetch, response.json() handles the parsing for you automatically.

Why `Content-Type: application/json` matters

When you send a request with a JSON body, you must tell the server what format the data is in using a header:

fetch('/api/jobs', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' }, // this line matters
  body: JSON.stringify({ company: 'Stripe' })
})

On the Express side, express.json() middleware reads this header. If it says application/json, it parses the body and puts it in req.body. If the header is missing or wrong — req.body is undefined. That's it. That's the entire reason forgetting this header breaks everything.

How Express reads your request — req.body vs req.params vs req.query

When a request reaches your Express controller, the data can be in three different places depending on how it was sent:

// req.params — data in the URL path
// Route: /jobs/:id
// Request: GET /jobs/42
req.params.id  // → "42"

// req.query — data in the URL after the ?
// Request: GET /jobs?status=applied
req.query.status  // → "applied"

// req.body — data in the request body (POST, PUT, PATCH)
// Requires express.json() middleware
req.body.company  // → "Stripe"

Simple rule — if it's in the URL it's params or query, if it's sent as data in the request body it's req.body.

The fetch API — why two awaits?

When you call fetch(), it doesn't give you your data directly. It gives you a Promise that resolves to a Response object. Then you need a second step to actually read the data:

const res = await fetch('/api/jobs');   // first await — gets the response headers
const data = await res.json();          // second await — reads and parses the body

Why two steps? Because of how the internet works.

The first await resolves the moment your browser receives the HTTP headers and status code from the server. But the actual body — the JSON data — might still be traveling across the network in packets. The second await res.json() waits for all those packets to arrive, assembles them, and parses the complete JSON string into a JavaScript object.

One important thing — fetch() only rejects (throws an error) if the network itself fails. A DNS failure, a dropped connection, a CORS block. If the server responds with a 404 or 500, fetch() still resolves successfully — because the network transaction worked, the server just returned an error status. This is why you need to check manually:

const res = await fetch('/api/jobs');

if (!res.ok) {
  // res.ok is true for 200-299, false for everything else
  throw new Error(`Request failed: ${res.status}`);
}

const data = await res.json();

CORS — the one that confuses everyone

Your React app runs on http://localhost:5173.
Your Express server runs on http://localhost:5000.

Different port = different origin.

Browsers have a built-in security rule called the Same-Origin Policy — a webpage cannot read responses from a different origin than the one it was served from. This exists to protect you. Without it, any random website you visit could silently make requests to your bank using your logged-in session and read your account data.

But in development you need your frontend to talk to your backend. That's what CORS solves — Cross-Origin Resource Sharing. It's a way for the server to say "yes, I trust this other origin, let it read my responses."

import cors from 'cors';

// Allow only your frontend
app.use(cors({ origin: 'http://localhost:5173' }));

// Allow everyone (fine for public APIs, dangerous for authenticated ones)
app.use(cors({ origin: '*' }));

The thing that makes CORS click

Here's what almost no tutorial explains clearly:

CORS is enforced by the browser, not the server.

When you make a cross-origin request, the request actually reaches the server. The server processes it and sends back a response. But then the browser intercepts that response, checks the Access-Control-Allow-Origin header, and if it doesn't see your frontend's origin listed — it throws the response away and shows you a CORS error.

You never got blocked from sending. You got blocked from reading the response.

This is why Postman never gets CORS errors. Postman is not a browser. It has no Same-Origin Policy. It sends the request, gets the response, and shows it to you directly — no security checks. The CORS error is the browser protecting the user, not the server rejecting you.

Preflight requests — why you sometimes see two requests

For requests that could modify data (POST, PUT, DELETE) or use custom headers, the browser doesn't just send your request straight away. It first sends a quick OPTIONS request — called a preflight — to ask the server "hey, are you okay with me sending this from this origin?"

OPTIONS /api/jobs HTTP/1.1
Origin: http://localhost:5173
Access-Control-Request-Method: POST

The server responds with what it allows. If the answer is yes, the browser then sends your actual request. If you ever see two requests in your Network tab when you expected one — that's the preflight.

Putting it all together

// Frontend — React component
useEffect(() => {
  fetch('http://localhost:5000/api/jobs')
    .then(res => {
      if (!res.ok) throw new Error('Request failed');
      return res.json();
    })
    .then(data => setJobs(data))
    .catch(err => console.error(err));
}, []);

// Backend — Express server
import cors from 'cors';
import express from 'express';

const app = express();
app.use(express.json());
app.use(cors({ origin: 'http://localhost:5173' }));

app.get('/api/jobs', async (req, res) => {
  const jobs = await pool.query('SELECT * FROM jobs');
  res.status(200).json(jobs.rows);
});

What happens when that useEffect runs:

fetch() sends GET http://localhost:5000/api/jobs
Browser checks — different origin, sends preflight OPTIONS first
Express responds — CORS allowed, proceed
Browser sends the real GET request
Express matches the route, queries the DB, sends back JSON
Browser checks Access-Control-Allow-Origin header — matches, passes response through
res.json() parses the JSON string into a JS array
setJobs(data) re-renders the component with real data

Common mistakes

1. Forgetting Content-Type: application/json in fetch
req.body will be undefined on the server. Always include the header when sending data.

2. Not checking res.ok after fetch
fetch() won't throw on a 404 or 500. You have to check res.ok yourself.

3. Thinking CORS is the server rejecting you
The server processed your request. The browser is blocking you from reading the response. Fix it by adding CORS headers on the server, not by changing your frontend code.

4. Using res.send() instead of res.json() for APIs
res.send() with a string sets Content-Type: text/html. Use res.json() which always enforces application/json — that's what your frontend expects.

5. Putting CORS middleware after your routes
Middleware runs in order. If CORS is registered after your routes, it never runs for those routes.

// Wrong
app.get('/api/jobs', getJobs);
app.use(cors()); // too late

// Right
app.use(cors()); // must come first
app.get('/api/jobs', getJobs);

Wrapping up

The frontend and backend are just two separate programs passing text messages to each other. REST is a naming convention that makes those messages predictable. JSON is the text format those messages use. And CORS is the browser being a responsible security guard — protecting users from malicious sites reading data they shouldn't.

Once you see it that way, none of it is magic anymore.

What Actually Happens When You Click a Button — From Browser to Database and Back

Prathamesh Dhadbale — Sun, 19 Apr 2026 08:25:15 +0000

You've written fetch(). You've set up an Express route. It works.

But do you actually know what happened in between? Most tutorials show you the pieces separately. Nobody walks you through the full conversation — browser to server to database and back — in one go.

Let's fix that.

The analogy that makes it click

Before we touch code, here's a mental model you'll never forget.

Think of it like ordering food at a restaurant:

You (the customer) = the browser
The waiter = the Express server / API
The kitchen = your controller + business logic
The pantry = the database

You don't walk into the kitchen and grab food yourself. You tell the waiter. The waiter goes to the kitchen. The kitchen checks the pantry, does its thing, and sends the food back through the waiter to your table.

That's a web request. Now let's trace it step by step.

Step 1 — User clicks a button (Browser)

Everything starts with an event on the frontend. The user clicks "Add Job" and a JavaScript event listener fires.

button.addEventListener('click', async () => {
  const response = await fetch('http://localhost:5000/api/jobs', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ company: 'Stripe', role: 'Frontend Intern' })
  });

  const data = await response.json();
  console.log(data);
});

Three things are happening inside that fetch() call:

method tells the server what kind of action you want — GET to read, POST to create, PUT to update, DELETE to remove
headers tell the server what format your data is in — here we're saying "I'm sending JSON"
body is your actual data, converted from a JS object into a JSON string using JSON.stringify()

Step 2 — The HTTP request travels to the server

Once fetch() fires, the browser packages your data into an HTTP request and sends it over the network. In production this goes over the internet. In development it stays on your machine via localhost.

Under the hood, the raw request looks like this:

POST /api/jobs HTTP/1.1
Host: localhost:5000
Content-Type: application/json

{"company":"Stripe","role":"Frontend Intern"}

Just structured text. That's genuinely all an HTTP request is — a text message with a specific format that both the browser and server agree to understand.

Step 3 — Express receives it and matches a route

Your Express server is sitting there, listening on port 5000, waiting for incoming requests.

import express from 'express';
const app = express();

app.use(express.json()); // parses the request body into req.body

app.post('/api/jobs', addJob); // POST + /api/jobs → runs addJob

app.listen(5000);

When a POST request comes in for /api/jobs, Express checks it against every registered route. Path matches? Method matches? It hands the request off to the addJob function.

But before addJob runs — middleware steps in.

Step 4 — Middleware runs first

Middleware is code that runs between the request arriving and your controller handling it. Think of it as a series of checkpoints your request must pass through.

// Logging — runs on every request
app.use((req, res, next) => {
  console.log(`${req.method} ${req.url}`);
  next(); // pass the request forward
});

// Auth — stops requests without a valid token
app.use((req, res, next) => {
  const token = req.headers.authorization;
  if (!token) return res.status(401).json({ error: 'Unauthorized' });
  next();
});

Each middleware either:

Calls next() → request moves forward to the next middleware or controller
Sends a response directly → request stops right there

express.json() is itself middleware — it reads the raw request body and converts it into a JS object on req.body. Without it, req.body is undefined and you'll spend 30 confused minutes wondering why.

Step 5 — Controller runs the business logic

Now your request finally reaches the controller — the function that handles the actual work.

export const addJob = async (req, res) => {
  const { company, role } = req.body;

  try {
    const result = await pool.query(
      'INSERT INTO jobs (company, role) VALUES ($1, $2) RETURNING *',
      [company, role]
    );

    res.status(201).json(result.rows[0]);
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: 'Something went wrong' });
  }
};

The controller pulls data from req.body, talks to the database, and sends back a response. Its only job is to connect the HTTP world to your database world.

Step 6 — The database stores the data

The line pool.query(...) sends a SQL command from your Node.js server to PostgreSQL:

INSERT INTO jobs (company, role)
VALUES ('Stripe', 'Frontend Intern')
RETURNING *;

What is `pool` and why not just a direct connection?

A connection pool keeps a set of database connections open and ready to reuse — instead of opening and closing a fresh connection for every single request, which is slow and expensive.

// db.js — PostgreSQL
import pg from 'pg';
const { Pool } = pg;

const pool = new Pool({
  connectionString: process.env.DATABASE_URL
});

export default pool;

For SQLite, it looks like this instead:

import { open } from 'sqlite';
import sqlite3 from 'sqlite3';

const db = await open({
  filename: './database.db',
  driver: sqlite3.Database
});

Different databases, same idea — your server needs a stable, efficient way to talk to them.

PostgreSQL runs the query, stores the row, and returns the newly created record because of RETURNING *. That result comes back as result.rows[0] in your controller.

Step 7 — The response travels back to the browser

Your controller sends:

res.status(201).json(result.rows[0]);

This builds an HTTP response and sends it back to the browser:

HTTP/1.1 201 Created
Content-Type: application/json

{"id":1,"company":"Stripe","role":"Frontend Intern"}

Back in the browser, your await fetch(...) resolves. response.json() parses that JSON string back into a JavaScript object. You now have the saved data on the frontend:

const data = await response.json();
setJobs(prev => [...prev, data]); // new job appears in the UI instantly

No page reload. Just a clean round trip.

Common mistakes to avoid

1. Forgetting express.json() middleware

req.body will be undefined. Always add app.use(express.json()) before your routes — not after.

2. Not awaiting response.json()

// Wrong — this is a Promise, not your data
const data = response.json();

// Right
const data = await response.json();

3. Sending a response twice in Express

// Wrong — both lines run, server crashes
if (!user) res.status(404).json({ error: 'Not found' });
res.json(user);

// Right — use return to stop execution
if (!user) return res.status(404).json({ error: 'Not found' });
res.json(user);

4. Confusing status codes with response data

Status 200 OK means the request completed — not that your data is correct. Always check both response.status and response.json().

When something breaks, trace it step by step

Now you have a map. Use it:

Is the request leaving the browser? → Check the Network tab in DevTools
Is it hitting the server? → Check your server terminal logs
Is the route matching? → Check your Express route definitions
Is the DB query working? → Test the query directly in your DB client
Is the response making it back? → Check response.status in the browser

Wrapping up

One click. Seven steps. Every time.

The click-to-database flow isn't magic — it's a structured conversation between your browser, your server, and your database. Each layer has one job. Together they make your app feel instant and alive.

Next time you write a fetch() call, you'll know exactly what's happening on the other side.

DEV Community: Prathamesh Dhadbale

How Frontend Talks to Backend — REST, JSON, and CORS Explained Without the Jargon

First — what even is an API?

What makes an API "REST"?

Status codes — the response's mood indicator

JSON — why everything uses it

Why Content-Type: application/json matters

How Express reads your request — req.body vs req.params vs req.query

The fetch API — why two awaits?

CORS — the one that confuses everyone

The thing that makes CORS click

Preflight requests — why you sometimes see two requests

Putting it all together

Common mistakes

Wrapping up

What Actually Happens When You Click a Button — From Browser to Database and Back

The analogy that makes it click

Step 1 — User clicks a button (Browser)

Step 2 — The HTTP request travels to the server

Step 3 — Express receives it and matches a route

Step 4 — Middleware runs first

Step 5 — Controller runs the business logic

Step 6 — The database stores the data

What is pool and why not just a direct connection?

Step 7 — The response travels back to the browser

Common mistakes to avoid

When something breaks, trace it step by step

Wrapping up

Why `Content-Type: application/json` matters

What is `pool` and why not just a direct connection?