How the Web Works

Every time you open a website, two things are talking to each other — the client and the server.

Think of it like searching on Google. When you type a query and hit Enter, your browser (the client) sends that request to Google's computers (the server). The server processes the request, finds the results, and sends them back to your browser, which displays the page. Every website visit works exactly this way.

Client — This is your browser (Chrome, Firefox, Safari). It's what you use to visit websites. When you type a URL and press Enter, your browser is the client asking for a page.

Server — This is a computer (somewhere out there on the internet) that stores website files and data. When your browser asks for a page, the server finds the files and sends them back.

A real example: when you open simplyjavascript.com, your browser sends a message to a server saying “hey, give me this page”. The server receives that message, grabs the HTML/CSS/JS files, and sends them back. Your browser then shows you the page.

Key things to know:

• Client = the one asking (usually your browser)
• Server = the one answering (a computer with files/data)
• Every website visit is a conversation between these two
• One server can talk to millions of clients at once

The conversation between a client and server happens through HTTP (HyperText Transfer Protocol). This is just a set of rules for how they talk to each other.

When a client wants something, it sends a Request. When the server responds, it sends back a Response.

A Request includes:

• Method — what kind of action (GET, POST, PUT, DELETE)
• URL — where to send the request (e.g. https://api.example.com/users)
• Headers — extra info like content type or auth tokens
• Body — data sent along (used in POST/PUT requests)

A Response includes:

• Status code — did it work? (200 = OK, 404 = Not Found, 500 = Server Error)
• Headers — info about the response
• Body — the actual data (HTML, JSON, image, etc.)

HTTP Methods — the most common ones:

• GET — fetch/read data (like opening a page)
• POST — send/create data (like submitting a form)
• PUT / PATCH — update existing data
• DELETE — remove data

Example: when you visit a product page on a shopping site, your browser sends a GET request to the server. The server finds the product info and sends back a response with status 200 OK and the product data in the body.

// A simple GET request (what your browser sends behind the scenes)
GET /products/123 HTTP/1.1
Host: shop.example.com

// The server responds:
HTTP/1.1 200 OK
Content-Type: application/json

{ "id": 123, "name": "Laptop", "price": 999 }

Common HTTP status codes you'll see a lot:

• 200 — Everything went fine
• 201 — Something was created (e.g. new user registered)
• 400 — Bad request (you sent something wrong)
• 401 — Unauthorized (you need to log in first)
• 403 — Forbidden (you don't have permission)
• 404 — Not found (the page/resource doesn't exist)
• 500 — Server error (something crashed on the server side)

API stands for Application Programming Interface. That sounds complicated, but the idea is simple.

An API is basically a way for two applications to talk to each other. It defines what requests you can make, what data you'll get back, and how to ask for it.

Think of an API like a TV remote. The remote gives you a set of buttons (endpoints) you can press to control the TV - volume, channels, power. You don't need to open the TV and rewire it yourself. Web APIs work the same way: they expose specific URLs you can call to get or send data, without you ever touching the server's internals.

On the web, APIs usually work over HTTP. You send a request to a specific URL (called an endpoint), and you get data back (usually in JSON format).

// Fetching data from a public API
fetch("https://jsonplaceholder.typicode.com/users/1")
  .then(response => response.json())
  .then(data => console.log(data));

// You get back something like:
// { id: 1, name: "Leanne Graham", email: "sincere@april.biz" }

APIs are everywhere:

• Weather apps get data from a weather API
• Zomato / Swiggy show restaurants by calling a maps API
• Login with Google uses Google's auth API
• Your banking app talks to the bank's API to show your balance

As a JavaScript developer, you'll use APIs constantly — to fetch data, send data, and connect your front-end to a back-end or third-party service.

REST stands for Representational State Transfer. Again, fancy name — simple idea.

REST is a set of rules (or style) for how to design APIs. When an API follows REST rules, we call it a RESTful API. Most modern web APIs are RESTful.

The main ideas behind REST:

• Resources — everything is a “resource” (a user, a product, a post). Each resource has its own URL.
• HTTP methods — use GET to read, POST to create, PUT/PATCH to update, DELETE to remove
• Stateless — each request is independent. The server doesn't remember your previous request
• JSON format — data is usually sent and received as JSON

Example of a RESTful API for a blog:

GET    /posts          ? get all posts
GET    /posts/5        ? get post with id 5
POST   /posts          ? create a new post
PUT    /posts/5        ? update post with id 5
DELETE /posts/5        ? delete post with id 5

See how clean that is? Each URL represents a resource. The HTTP method tells the server what to do with it. That's REST in a nutshell.

Real example using fetch():

// GET all posts
fetch("https://jsonplaceholder.typicode.com/posts")
  .then(res => res.json())
  .then(posts => console.log(posts));

// POST a new post
fetch("https://jsonplaceholder.typicode.com/posts", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ title: "Hello", body: "World", userId: 1 })
})
  .then(res => res.json())
  .then(data => console.log(data));

CORS is something you'll definitely run into as a web developer — usually when your code breaks with a confusing error in the console.

What is CORS?

By default, browsers have a security rule: a webpage can only make requests to the same origin (same domain, protocol, and port) it was loaded from. This is called the Same-Origin Policy.

For example, a page at https://mysite.com cannot normally make a request to https://api.someothersite.com. The browser blocks it.

This is where CORS comes in. CORS is a mechanism that lets servers say: “yes, I allow requests from this other origin.”

The server does this by adding special headers to its response:

// Server response header that allows all origins:
Access-Control-Allow-Origin: *

// Or allow only a specific site:
Access-Control-Allow-Origin: https://mysite.com

If the server doesn't include this header, your browser will block the response and you'll see an error like:

Access to fetch at 'https://api.someothersite.com/data'
from origin 'https://mysite.com' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

This error is thrown by the browser — not the server. The server actually received the request and responded. But the browser saw that the CORS header was missing and refused to pass the response to your code.

Important things to know about CORS:

• CORS is a browser security feature — it doesn't affect server-to-server requests
• The fix is on the server side — you need to add the correct headers
• If you control the API, you enable CORS in your back-end code
• If you don't control the API, you might need a proxy server
• Using * as the origin allows any website to call your API — use it carefully

• The client (your browser) sends a request to the server, and the server sends back a response.
• Requests have a method (GET, POST, PUT, DELETE), a URL, headers, and optionally a body.
• Responses have a status code (200, 404, 500, etc.), headers, and a body with the data.
• An API is a way for two applications to communicate — it exposes endpoints you can call to get or send data.
• REST is a design style for APIs: use URLs to represent resources, use HTTP methods to define actions, keep requests stateless.
• CORS is a browser security rule that blocks cross-origin requests unless the server explicitly allows them via response headers.
• CORS errors are browser-side — the fix is always on the server by adding Access-Control-Allow-Origin headers.

• What is the difference between a client and a server?
• What is HTTP and what role does it play in web communication?
• What are the common HTTP methods and when do you use each one?
• What does a status code of 200, 404, and 500 mean?
• What is an API? Give a real-world example.
• What is a REST API? What makes an API RESTful?
• What does “stateless” mean in REST?
• What is CORS and why does it exist?
• Why does a CORS error happen and where do you fix it?
• Can server-to-server requests have CORS issues? Why or why not?
• What is the Access-Control-Allow-Origin header used for?
• What is the Same-Origin Policy?