HTTP, Requests and Responses | IT Foundations for Beginners

In this chapter

We'll learn HTTP, the language browsers and servers speak — explained as filling in a standard order form — including requests and responses, HTTP methods, status codes, headers, and why HTTPS matters.

14–16 min

The Problem in Real Life

With Northgate fixed, Anna wants to see a real conversation between a browser and BlueTicket's server. John shows her the Network tab in the browser's developer tools (F12). She reloads the event page, and dozens of lines appear — one for every file the page asked for.

She clicks the first line. It's full of words she's seen in error messages for years but never understood: GET, 200 OK, Content-Type, 304. "So this is what browsers and servers actually say to each other?"

Every page you've ever loaded was a short, polite conversation: a request, and a response.

John

"The Page Loads" vs. the Conversation Behind It

Browsers and servers need a shared language

Millions of different browsers and servers can only understand each other if they all follow the same rules.

Every page is many requests

One page is often dozens of separate requests: the page, the images, the styles, the data.

Numbers tell you what happened

Status codes like 404 and 500 tell you exactly which side had a problem — if you can read them.

HTTP: Requests, Responses, Methods, Status Codes and Headers

The order form analogy: imagine a huge warehouse that only accepts orders on a standard printed form. Every form has the same boxes: what you want to do (order, return, change), which item, your details, and any notes. The warehouse replies with a standard slip too: a result code ("done," "not found," "we had a problem"), a few details, and the item itself. Because everyone uses the same forms, any customer can deal with any warehouse. HTTP is that standard form for the web.

HTTP (HyperText Transfer Protocol) is the set of rules for how clients ask for web resources and how servers answer. Every HTTP conversation is one request and one response.

Request — the order form the client sends: a request contains a method (what you want to do), a path (which resource, like /events/festival), headers (extra details about the request), and sometimes a body (data you're sending, like a filled-in form).
Response — the slip the server sends back: a response contains a status code (what happened), headers (details about the answer, like what type of content it is), and usually a body (the actual content: HTML for a page, an image, or data).
Methods — the "what do you want to do?" box: GET asks for something (show me the event page). POST sends something new (create this booking). PUT replaces something, PATCH changes part of it (update my phone number). DELETE removes something (cancel this hold). Most of the web is GET and POST.
Headers — the extra details on the form: headers are name-value lines that travel with requests and responses. A request might say User-Agent: Chrome (which browser) or Accept-Language: en (preferred language). A response might say Content-Type: text/html (this is a web page) or Cache-Control: max-age=3600 (you may reuse this for an hour — more in Act 12).

Table — HTTP methods

Method	Means	Example at a ticketing company
GET	Read something	Show the festival event page
POST	Create something new	Create a seat hold or a booking
PUT	Replace something	Replace a fan's whole profile
PATCH	Change part of something	Update just the phone number
DELETE	Remove something	Cancel a hold

Table — Status codes you'll see most

Code	Name	Means	Whose problem?
200	OK	It worked	Nobody's
201	Created	Something new was made	Nobody's
301	Moved Permanently	It lives at a new address now	Nobody's
304	Not Modified	Your saved copy is still good	Nobody's
400	Bad Request	The request was filled in wrong	The client's
401	Unauthorized	You need to log in	The client's
403	Forbidden	You're not allowed	The client's
404	Not Found	No such page	The client's (wrong address)
500	Internal Server Error	A bug on the server	The server's
503	Service Unavailable	Overloaded or down	The server's

Table — HTTP vs. HTTPS

Feature	HTTP	HTTPS
Everyday version	A postcard	A sealed, tamper-proof envelope
Can others read it on the way?	Yes	No — encrypted
Can others change it on the way?	Yes	No — changes are detected
Usual port	80	443
Use it for	Almost nothing today	Everything — especially logins and payments

One HTTP conversation

Request (from the browser)

GET /events/festival · headers · no body

travels to the server

Server

finds the page, builds the answer

travels back

Response (from the server)

200 OK · Content-Type: text/html · the page

Browser shows the page

then sends more requests for images, styles, data

This is the actual text that travels (inside the HTTPS envelope). Each line is a box on the form.

What a request and a response really look like

GET /events/festival HTTP/1.1          <- method, path, version
Host: blueticket.example               <- headers: which site
User-Agent: Chrome/131
Accept-Language: en

HTTP/1.1 200 OK                        <- status code
Content-Type: text/html; charset=utf-8 <- headers: what kind of content (and Act 03's UTF-8!)
Cache-Control: max-age=60

<!doctype html> ... the page ...       <- body

Status codes — the result box, in five families: every response starts with a three-digit number, and the first digit tells you the family. 1xx — wait, still working (rare). 2xx — success: 200 OK, 201 Created (a new booking was made). 3xx — go elsewhere: 301 Moved Permanently, 304 Not Modified ("your saved copy is still good"). 4xx — the client made a mistake: 400 Bad Request (the form was filled in wrong), 401 Unauthorized (please log in), 403 Forbidden (you're logged in but not allowed), 404 Not Found (no such page). 5xx — the server had a problem: 500 Internal Server Error (a bug on the server), 503 Service Unavailable (overloaded or down). A simple rule of thumb: 4xx is "you did something wrong," 5xx is "we did something wrong."

HTTP vs. HTTPS — a postcard vs. a sealed envelope: plain HTTP is like a postcard: everyone who handles it on the way — the campus network, the ISP, anyone on the same café Wi-Fi — can read it, and even change it. HTTPS is HTTP sent inside a sealed, tamper-proof envelope: the same requests and responses, but encrypted, so only the browser and the server can read them, and they can tell if anyone changed them. Every login, payment and personal detail must travel over HTTPS — and today almost the whole web does. The sealing is done by TLS, in the next chapter.

Reading Anna's Network tab: the first line is GET /events/festival → 200 OK, Content-Type: text/html — the page itself. Then dozens of GET requests for images, styles and scripts, mostly 200, some 304 (the browser's saved copy is still fine, so nothing needed to be downloaded again). When she picks a seat, a new line appears: POST /api/holds → 201 Created. And when she tries an old link, GET /events/old-show → 404 Not Found. For the first time, the conversation makes sense.

Key Takeaway

HTTP is the web's standard order form: a client sends a request (method, path, headers, optional body) and the server returns a response (status code, headers, body). Methods say what to do — GET to read, POST to create, PUT/PATCH to change, DELETE to remove. Status codes say what happened: 2xx success, 3xx go elsewhere, 4xx the client's mistake, 5xx the server's. HTTPS is the same conversation in a sealed, encrypted envelope.

Why This Matters

HTTP is the language of the entire web and of almost every API. Reading methods and status codes is one of the most-used skills in any web job: a 401 means check the login, a 404 means check the address, a 500 means look at the server logs (Act 06), a 503 means the server is overloaded — which is exactly what BlueTicket will fight on Sale Day.

Anna can read the conversation now. But she wonders what's underneath it: how do these requests travel reliably across all those networks, and how exactly does HTTPS seal the envelope?