How the Web Works

When you open a website, the main participants are the client and the server.

The browser sends a request for a resource, such as an HTML page, and a server processes that request and sends a response. Many web interactions follow this client-server pattern.

Client - A client is a program that requests resources or services from a server. In web applications, the browser is usually the client.

Server - A server is a computer or software system that receives requests and provides resources or services in response.

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 system providing a resource or service
• Many website interactions involve requests from a client and responses from a server
• One server can talk to millions of clients at once

HTTP (HyperText Transfer Protocol) is a protocol used for communication between clients and servers on the web. A client sends an HTTP request, and the server sends an HTTP response.

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 - optional data sent along with the request, commonly when submitting data

A Response includes:

• Status code - did it work? (200 = OK, 404 = Not Found, 500 = Server Error)
• Headers - info about the response
• Body - the returned data, such as HTML, JSON, text, images, or other content

HTTP Methods - the most common ones:

• GET - fetch/read data (like opening a page)
• POST - submit data, often to create a resource
• PUT - replace a resource
• PATCH - partially update a resource
• DELETE - delete a resource

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 - the request succeeded
• 201 - a resource was created successfully
• 400 - the server could not process the request because it was invalid
• 401 - authentication is required or failed
• 403 - the server understood the request but refuses access
• 404 - the requested resource was not found
• 500 - the server encountered an unexpected error

HTTPS is HTTP sent through TLS (Transport Layer Security). The browser and server establish an encrypted connection before exchanging the request and response. The lock icon means the connection is protected; it does not guarantee that a website itself is honest or that every piece of content is safe.

• Confidentiality: encryption makes it difficult for someone on the network to read the traffic.
• Integrity: TLS helps detect whether traffic was changed in transit.
• Authentication: certificates help the browser verify that it connected to the domain it requested.

A certificate does not replace good application security. Never put passwords or secret API keys in URLs, validate data on the server, and use secure cookies for session credentials.

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

An API defines how one application can request data or perform operations provided by another application or service. It specifies the requests that are available, the data they accept, and the responses they return.

Web APIs commonly expose specific URLs called endpoints. Another application can call those endpoints to get or send data without needing access to the server's internal implementation.

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 (Representational State Transfer) is an architectural style for designing networked APIs. An API designed around these principles is often called a RESTful API.

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 requests - each request contains the information needed to process it; the server does not rely on stored context from a previous request
• Representations - resources can be represented using formats such 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

Each URL identifies a resource, and the HTTP method communicates the intended operation. This is a common REST design pattern, although these elements alone do not make an API fully RESTful.

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?

Browsers enforce the Same-Origin Policy, which restricts JavaScript from reading responses from different origins unless the server allows that access through CORS. An origin is defined by its scheme, host, and port.

For example, JavaScript running on https://mysite.com may request https://api.someothersite.com, but browser JavaScript cannot read the response unless the server permits that origin.

CORS (Cross-Origin Resource Sharing) is a mechanism that allows a server to specify which other origins may access its responses from browser-based JavaScript.

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 response does not satisfy the CORS rules, browser JavaScript is prevented from reading the response and you may 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.

The browser may send the request to the server, but if the response does not satisfy the CORS rules, browser JavaScript is prevented from reading that response. The server may have received and processed the request even though your code cannot access the response.

Important things to know about CORS:

• CORS is a browser security feature - it doesn't affect server-to-server requests
• If you control the API, CORS is usually configured on the server by returning the appropriate response headers
• If you don't control the API, you may need a server-side proxy or another architecture that avoids the browser cross-origin restriction
• Using * as the origin allows any website to call your API - use it carefully

A browser cache stores reusable responses such as images, CSS, JavaScript, and API data. On a later visit, the browser can reuse a fresh response instead of downloading it again, which reduces waiting and network work.

Servers control caching with headers:

Cache-Control: public, max-age=31536000, immutable
ETag: "assets-v3"

// For data that must be checked frequently:
Cache-Control: no-cache

max-age tells the browser how long a response can be reused. An ETag lets the browser ask whether a cached response changed. no-cache means the browser may store the response but should validate it before reuse; it does not necessarily mean “do not store anything.”

A beginner performance check

1. Open DevTools and choose the Network panel. Reload with the panel open.
2. Check the Size, Time, status, and Waterfall for the largest or slowest resources.
3. Reload again and look for from memory cache or from disk cache.
4. Use the Performance panel for long JavaScript tasks and the Lighthouse panel for page-load opportunities.
5. Improve one bottleneck: compress or resize images, defer non-critical scripts, reduce requests, or set appropriate cache headers. Measure again.

• 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 an architectural style for networked APIs: use URLs to represent resources, HTTP methods to communicate intended actions, stateless requests, and representations such as JSON.
• CORS is a browser security mechanism that controls whether JavaScript can access responses from another origin based on the server's CORS headers.
• CORS errors are enforced by the browser. If you control the API, configure the appropriate CORS policy on the server.
• HTTPS uses TLS to protect confidentiality, integrity, and domain authentication during HTTP communication.
• Caching lets browsers reuse responses. Use Network, Performance, and Lighthouse panels to find download and rendering bottlenecks.

• 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?