Introduction & Learning Goals

🎯 What You'll Learn

🌐 HTTP Protocol

Client-server architecture
Request/response cycle
Status codes & headers

⚡ JavaScript Core

Functions, objects & arrays
Async: Promises & async/await
Modern ES6+ syntax

🖥️ Browser APIs

DOM manipulation
Events & event handling
Fetch API & AJAX

🚀 Node.js

Server-side JavaScript
File system & modules
Building APIs

📚 Course Flow

HTTP Basics → JS Refresher → Browser → Node.js

Understand how the web works: clients, servers, and HTTP.
Refresh core JavaScript concepts and modern patterns.
Apply JavaScript in the browser (DOM) and on the server (Node.js).

Web Foundations: HTTP

Scenario

The initiator of an HTTP request is the client in that exchange. Your server can also call other servers (external APIs) — in that request, your server is the client. Client vs server describes who starts the request; client‑side vs server‑side describes where code runs.

👥 Understanding the Actors

Every HTTP request involves a client and a server

🔄 Roles per request

A client starts a request; a server answers. In chains (your server → external API) the roles switch per hop.

Why ports

One IP, many apps. The OS delivers packets to the process bound to the destination port.

DNS → IP

Resolve example.com to an IP (cached by TTL). CDNs often answer with a nearby edge.

Connect, then HTTP

TCP 3‑way → TLS (for HTTPS) → send request line + headers → receive response.

Advanced: routing & sockets

Reverse proxy routing: 443 (Nginx) can route api.example.com → localhost:8000, www.example.com → localhost:3000, assets → localhost:9000.
Ephemeral client ports: Each connection is a 4‑tuple (clientIP:clientPort ⇄ serverIP:serverPort), e.g. 198.51.100.24:53214 ⇄ 203.0.113.10:443.
Anycast/CDN: One advertised IP maps to multiple edges; DNS and BGP steer you to a close POP.

Anatomy of HTTP Messages

A message = start line + headers + optional body. Each part has distinct semantics. Dive deeper for framing, wire format, and caching implications.

Status Codes: Semantics & Strategy

Status codes drive caching, retries, SEO, monitoring and auth flows before any body is read. Use precise codes consistently; guesswork costs performance.

Headers & Content Types (Quick View)

Headers = metadata; start line + headers often decide caching, routing, auth before body is read. Content type tells parsers how to treat the body.

Negotiation: Accept, Content-Type
Caching: Cache-Control, ETag, validators
Auth: Authorization, WWW-Authenticate
Session: Cookie, Set-Cookie
Compression: Accept-Encoding/Content-Encoding
Trace: Traceparent, X-Request-ID
Representation: JSON, HTML, multipart, binary

Communication Examples

GET Request

A simple GET request to fetch a list of users. The client specifies it accepts JSON responses.

GET /api/users HTTP/1.1
Host: example.com
Accept: application/json

POST Request

A POST request to create a new user. The body contains JSON data with the user's information.

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{"name":"Mehdi","role":"student"}

Server Response

A successful response with caching headers, compression, and an ETag for future revalidation.

HTTP/1.1 200 OK
Date: Thu, 06 Nov 2025 10:11:12 GMT
Server: example-app
Content-Type: application/json; charset=utf-8
Cache-Control: max-age=60, public
ETag: "users:v1:af31b2"
X-Request-ID: 8b7c2f55-91d7-4e6a-8209-9f8a1f4c1c21
Content-Encoding: br

[{"id":1,"name":"Mehdi"},{"id":2,"name":"Ada"}]

Reading the response without the body: Status + headers already tell success, cacheability, compression, and revalidation strategy (ETag). Monitoring often ignores the body.

Anatomy of HTTP Messages

Start Line

GET /api/users HTTP/1.1

Method + Path + Version (request) or Version + Status + Reason (response)

Headers

Host: example.com
Accept: application/json
Authorization: Bearer ...

Key: Value pairs. Control caching, auth, content type, routing.

Empty Line

↵

CRLF separator between headers and body. Required.

Body

{"name":"Mehdi","role":"student"}

Optional. Format defined by Content-Type header. Can be JSON, HTML, binary, etc.

Intermediaries

Often ignore body for decisions
Rely on headers for caching/retries/compression

Message Examples

Framed Examples

GET /api/users?page=1 HTTP/1.1
Host: example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Cache-Control: max-age=60, public
ETag: "users:v1:af31b2"

[{"id":1,"name":"Mehdi"},{"id":2,"name":"Ada"}]

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=120, public

<!doctype html>
<html>
  <head><title>Example</title></head>
  <body>
    <h1>Hello from the web server</h1>
    <!-- …rest of the page omitted… -->
  </body>
</html>

Legend: start line • headers • blank line • body. Tip: GET requests do not include a body; use query parameters or POST for complex searches.

Status Codes: Semantics

2xx Success

200 OK
201 Created
204 No Content
206 Partial

3xx Redirect

301 Permanent
302 Temp
303 See Other
304 Not Modified
307/308 Preserve method

4xx Client

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
409 Conflict
422 Unprocessable
429 Rate Limit

5xx Server

500 Error
502 Bad Gateway
503 Unavailable
504 Timeout

Status Code Patterns (Design Guide)

Apply a consistent decision tree: (1) Did the request succeed? (2) If not, is the fault on the client (4xx) or server (5xx)? (3) Pick the most specific code; never tunnel errors through 200.

Auth vs Authorization

401 No/expired credentials → include WWW-Authenticate.
403 Credentials valid but action forbidden (scope/role).
Rule: Can supplying new credentials help? If yes → 401 else 403.

{
  "error":"forbidden",
  "required_role":"admin"
}

Validation & Semantics

400 Malformed (parse/type error).
422 Well‑formed but domain rule failed.
409 Version / uniqueness / state conflict.
410 Resource intentionally removed (stop retrying).

{
  "error":"validation",
  "field_errors":[{"field":"email","issue":"already taken"}]
}

Caching & Conditionals

200 Fresh; send ETag/Cache-Control.
304 Validator matched (If-None-Match/If-Modified-Since).
Rule: Always emit a strong validator for cacheable GETs.

GET /items
If-None-Match: "rev-27"
→ 304 Not Modified

Retries & Resilience

502 Upstream error (dependency failed).
503 Temporary overload / maintenance (add Retry-After).
504 Upstream timeout.
Retry only idempotent methods (GET, HEAD, OPTIONS, safe DELETE, some PUT).

HTTP/1.1 503 Service Unavailable
Retry-After: 120
{"error":"overloaded"}

Rate Limiting

429 Too Many Requests (quota window exceeded).
Return: Retry-After, X-RateLimit-Remaining, X-RateLimit-Reset.
Rule: Use 429 (not 403) for transient quota exhaustion.

HTTP/2 429
Retry-After: 5
X-RateLimit-Remaining: 0
{"error":"rate_limit","retry_in":5}

Bulk / Partial

207 Multi-Status (mixed results) OR
200 with per-item status objects.
Prefer 200 + array unless spec needs 207.

{
  "results":[
    {"id":1,"status":201},
    {"id":2,"status":409,"error":"duplicate"}
  ]
}

Ranges / Downloads

206 Partial Content (serve byte range).
416 Invalid range request.

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/4096

Idempotent Mutations

PUT replace → 200 (return body) or 204 (no body).
PATCH partial update → 200/204; use 409 on version mismatch.
DELETE existing or already deleted → often always 204 to be idempotent.

Error Envelope

Shape: { error, message?, details?, trace_id? }.
No stack traces in prod; supply correlation id.
Never use 200 with an error wrapper.

{
  "error":"conflict",
  "message":"Version mismatch",
  "expected_version":12
}

Decision Cheatsheet

Malformed JSON: 400
Business rule fail: 422
Concurrent update: 409
Missing auth: 401
Not allowed: 403
Over capacity: 503 + Retry-After
Rate limited: 429
Removed resource: 410

JavaScript Overview

⚙️ How JavaScript Works

📝

Your Code

.js files

→

🔧

JS Engine

V8, SpiderMonkey

→

⚡

Execution

Machine code

Single-Threaded

One task at a time

Event Loop

Handles async operations

ECMAScript

Language standard

Non-Blocking

Async I/O operations

Engines & the Language

JS engines (like V8, SpiderMonkey) implement the ECMAScript standard. JS is single‑threaded with an event loop; asynchronous work uses callbacks, promises, and async/await.

Core Concepts at a Glance

Types, variables, functions, and arrow functions
Objects and this semantics
Arrays and array methods (map, filter, reduce, sort)
Errors, try/catch, and promises

Deep dive in the Language Refresher.

Node.js Runtime

🚀 Node.js Architecture

📝 Your JavaScript Code

↓

🔧 Node.js APIs

fs, http, path, crypto...

↓

V8 Engine

JS execution

libuv

Async I/O

↓

💻 Operating System

Files, Network, Processes

Common Use Cases:

🌐 REST APIs ⚡ Real-time apps 💻 CLI tools 🔗 Microservices

Idea behind Node.js

Node.js runs JavaScript on the server using the V8 engine plus system bindings for files, network, and more. It’s great for I/O‑heavy apps.

Learn more

See the dedicated Node.js page for examples and patterns.

🚀 Ready to go deeper?

Continue to JavaScript Refresher

Strengthen your JavaScript fundamentals with modern ES6+ syntax, functions, objects, and async patterns.

📦 Variables & Types

⚡ Functions & Objects

🔄 Async & Promises

Explore JS Refresher

{ }

</>

DOM

Introduction & Learning Goals

🎯 What You'll Learn

📚 Course Flow

Web Foundations: HTTP

👥 Understanding the Actors

🔄 Roles per request

Why ports

DNS → IP

Connect, then HTTP

Anatomy of HTTP Messages

Status Codes: Semantics & Strategy

Headers & Content Types (Quick View)

Communication Examples

GET Request

POST Request

Server Response

JavaScript Overview

⚙️ How JavaScript Works

Engines & the Language

Core Concepts at a Glance

Node.js Runtime

🚀 Node.js Architecture

Idea behind Node.js

Learn more

Continue to JavaScript Refresher

⌨️ Keyboard Shortcuts