HTTP Request and Response

Every interaction on the web is a request from a client and a response from a server. Understand the anatomy of both.

Beginner20 min study9 min read

Learning objectives

Describe the client–server model and where HTTP fits.
Identify the parts of an HTTP request: method, path, headers, body.
Identify the parts of an HTTP response: status line, headers, body.
Explain why HTTP is a stateless protocol and what that implies.

Simple explanation

Imagine walking up to a counter at a library. You hand over a slip that says *"I'd like the book with ID 42, please"*. The librarian goes to the shelf, finds it, and hands it back with a note: *"Here it is."* Or maybe: *"Sorry, that book doesn't exist."* That exchange — one request, one response — is exactly how HTTP works.

HTTP (HyperText Transfer Protocol) is the language browsers and servers use to talk. The client (your browser, a mobile app, another server) sends a request. The server processes it and sends back a response. Nothing more, nothing less.

Technical explanation

An HTTP request has four parts:

Request line — the method, the target path, and the HTTP version, e.g. GET /users/42 HTTP/1.1.
Headers — key–value metadata: who you are (User-Agent), what formats you accept (Accept), authentication (Authorization), and so on.
Blank line — a single empty line that separates headers from the body.
Body (optional) — the payload, used mostly with POST, PUT, and PATCH (e.g. JSON data).

An HTTP response mirrors that structure:

Status line — the HTTP version, a status code, and a reason phrase, e.g. HTTP/1.1 200 OK.
Headers — metadata about the response: Content-Type, Content-Length, Cache-Control, etc.
Blank line.
Body — the actual content (HTML, JSON, an image, …).

Why it matters

Almost everything you build as a developer travels over HTTP: web pages, REST APIs, mobile backends, webhooks. If you understand the request/response cycle deeply, you can debug why an API returns the wrong data, why a page won't cache, or why authentication fails — instead of guessing.

How it works

The full cycle for a typical page load:

The browser resolves the domain to an IP (DNS lookup).
It opens a TCP connection (and a TLS handshake for HTTPS).
It sends an HTTP request over that connection.
The server routes the request, runs your application code, and builds a response.
The response travels back; the browser renders it or the app parses it.
The connection may stay open (keep-alive) for further requests.

Real-world analogy

Think of HTTP like ordering at a restaurant. You (the client) place a specific order (the request) with all the details the kitchen needs. The kitchen (the server) prepares it and the waiter brings back either your food (a 200 OK with a body) or an apology that the dish is unavailable (a 404 or 503). Each order is independent — the kitchen doesn't remember your last visit unless you carry a loyalty card (a cookie or token). That "no memory" property is statelessness.

Important terminology

Statelessness — the server keeps no memory of previous requests. Each request must carry everything it needs (auth tokens, session ids). State is added on top via cookies, tokens, or server-side sessions.
Idempotency — sending the same request multiple times has the same effect as sending it once (true for GET, PUT, DELETE; not for POST).
MIME type / Content-Type — declares the format of the body, e.g. application/json.

Key definitions

Client: The party that initiates a request — a browser, mobile app, or another service.
Server: The party that receives the request, processes it, and returns a response.
Header: Key–value metadata attached to a request or response, e.g. Content-Type or Authorization.
Stateless: HTTP retains no memory between requests; each request is self-contained.

Must memorize

A request = request line + headers + blank line + optional body.
A response = status line + headers + blank line + body.
HTTP is stateless — the server remembers nothing between requests by default.
Content-Type tells the receiver how to interpret the body.

Real-world example

Logging into a web app

Your browser sends a POST request to /login with a JSON body containing credentials. The server verifies them and responds with 200 OK plus a Set-Cookie header. Every later request includes that cookie so the stateless server can recognize you.

Code example

request.http

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

{
  "name": "Ada Lovelace",
  "email": "ada@example.com"
}

A raw HTTP request with a JSON body.

response.http

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/42
Content-Length: 68

{
  "id": 42,
  "name": "Ada Lovelace",
  "email": "ada@example.com"
}

The matching HTTP response.

fetch.js

const res = await fetch('https://api.example.com/api/users', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: 'Bearer ' + token,
  },
  body: JSON.stringify({ name: 'Ada Lovelace', email: 'ada@example.com' }),
});

console.log(res.status); // 201
const user = await res.json();

Making the same request from JavaScript with fetch.

Common mistakes

Mistake

Assuming the server "remembers" the previous request automatically.

Do this instead

HTTP is stateless. Carry state explicitly via cookies, tokens, or session ids on every request.

Mistake

Putting sensitive data in the URL query string.

Do this instead

URLs are logged and cached. Send secrets in headers or the request body over HTTPS.

Interview questions

Quiz

Question 1 of 30 ✓

Which statement best describes HTTP?

Select an answer to continue.

Flashcards

Card 1 of 3

Show answer · Space

Summary

HTTP is a stateless request/response protocol. A request carries a method, path, headers, and optional body; a response carries a status code, headers, and body. Because the server keeps no memory between requests, state is layered on with cookies and tokens.

References

HTTP Request and Response

Every interaction on the web is a request from a client and a response from a server. Understand the anatomy of both.

Beginner20 min study9 min read

Export PDF

Learning objectives

Describe the client–server model and where HTTP fits.
Identify the parts of an HTTP request: method, path, headers, body.
Identify the parts of an HTTP response: status line, headers, body.
Explain why HTTP is a stateless protocol and what that implies.

Simple explanation

Technical explanation

An HTTP request has four parts:

Request line — the method, the target path, and the HTTP version, e.g. GET /users/42 HTTP/1.1.
Headers — key–value metadata: who you are (User-Agent), what formats you accept (Accept), authentication (Authorization), and so on.
Blank line — a single empty line that separates headers from the body.
Body (optional) — the payload, used mostly with POST, PUT, and PATCH (e.g. JSON data).

An HTTP response mirrors that structure:

Status line — the HTTP version, a status code, and a reason phrase, e.g. HTTP/1.1 200 OK.
Headers — metadata about the response: Content-Type, Content-Length, Cache-Control, etc.
Blank line.
Body — the actual content (HTML, JSON, an image, …).

Why it matters

How it works

The full cycle for a typical page load:

The browser resolves the domain to an IP (DNS lookup).
It opens a TCP connection (and a TLS handshake for HTTPS).
It sends an HTTP request over that connection.
The server routes the request, runs your application code, and builds a response.
The response travels back; the browser renders it or the app parses it.
The connection may stay open (keep-alive) for further requests.

Real-world analogy

Important terminology

Statelessness — the server keeps no memory of previous requests. Each request must carry everything it needs (auth tokens, session ids). State is added on top via cookies, tokens, or server-side sessions.
Idempotency — sending the same request multiple times has the same effect as sending it once (true for GET, PUT, DELETE; not for POST).
MIME type / Content-Type — declares the format of the body, e.g. application/json.

Key definitions

Client: The party that initiates a request — a browser, mobile app, or another service.
Server: The party that receives the request, processes it, and returns a response.
Header: Key–value metadata attached to a request or response, e.g. Content-Type or Authorization.
Stateless: HTTP retains no memory between requests; each request is self-contained.

Must memorize

A request = request line + headers + blank line + optional body.
A response = status line + headers + blank line + body.
HTTP is stateless — the server remembers nothing between requests by default.
Content-Type tells the receiver how to interpret the body.

Real-world example

Logging into a web app

Code example

request.http

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

{
  "name": "Ada Lovelace",
  "email": "ada@example.com"
}

A raw HTTP request with a JSON body.

response.http

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/42
Content-Length: 68

{
  "id": 42,
  "name": "Ada Lovelace",
  "email": "ada@example.com"
}

The matching HTTP response.

fetch.js

const res = await fetch('https://api.example.com/api/users', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: 'Bearer ' + token,
  },
  body: JSON.stringify({ name: 'Ada Lovelace', email: 'ada@example.com' }),
});

console.log(res.status); // 201
const user = await res.json();

Making the same request from JavaScript with fetch.

Common mistakes

Mistake

Assuming the server "remembers" the previous request automatically.

Do this instead

HTTP is stateless. Carry state explicitly via cookies, tokens, or session ids on every request.

Mistake

Putting sensitive data in the URL query string.

Do this instead

URLs are logged and cached. Send secrets in headers or the request body over HTTPS.

Interview questions

Quiz

Question 1 of 30 ✓

Which statement best describes HTTP?

Select an answer to continue.

Flashcards

Card 1 of 3

Show answer · Space

HTTP Request and Response

Learning objectives

Simple explanation

Technical explanation

Why it matters

How it works

Real-world analogy

Important terminology

Key definitions

Must memorize

Real-world example

Logging into a web app

Code example

Common mistakes

Interview questions

Quiz

Flashcards

Summary

References

Related topics

HTTP Request and Response

Learning objectives

Simple explanation

Technical explanation

Why it matters

How it works

Real-world analogy

Important terminology

Key definitions

Must memorize

Real-world example

Logging into a web app

Code example

Common mistakes

Interview questions

Quiz

Flashcards

Summary

References

Related topics

Learning objectives

Simple explanation

Technical explanation

Why it matters

How it works

Real-world analogy

Important terminology

Key definitions

Must memorize

Real-world example

Logging into a web app

Code example

Common mistakes

Interview questions

What does it mean that HTTP is stateless, and how do applications maintain state?

Walk me through the parts of an HTTP request and response.

Quiz

Flashcards

Summary

References

Related topics

Learning objectives

Simple explanation

Technical explanation

Why it matters

How it works

Real-world analogy

Important terminology

Key definitions

Must memorize

Real-world example

Logging into a web app

Code example

Common mistakes

Interview questions

What does it mean that HTTP is stateless, and how do applications maintain state?

Walk me through the parts of an HTTP request and response.

Quiz

Flashcards

Summary

References

Related topics