3 lessons and a self-check quiz. Tap Next to begin.
Every app you build rides on one exchange repeated billions of times a day: a client sends a request, a server sends a response. Understand this precisely and networking stops being magic.
A raw HTTP request is just text. Here is roughly what the browser sends and gets back:
GET /api/bookings?date=2026-08-01 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGci...
--- response ---
HTTP/1.1 200 OK
Content-Type: application/json
{ "bookings": [ { "id": 1, "time": "18:00" } ] }Top: a GET request with headers. Bottom: a 200 OK response whose body is JSON.
| Status | Meaning | You will use it when |
|---|---|---|
| 200 OK | Success, body included | A read or update worked |
| 201 Created | New resource made | A POST created a record |
| 400 Bad Request | Client sent bad data | Validation failed |
| 401 Unauthorized | Not logged in | Missing/invalid token |
| 404 Not Found | No such resource | ID doesn’t exist |
| 500 Server Error | Your code threw | An unhandled exception |
A user submits a form to create an account and the server succeeds. Which status code is most correct?
Tap an answer to check it — instant feedback, nothing graded.
HTML is the skeleton — it describes what content is, not how it looks. A real page is a tree of nested elements. Here is a minimal but correct HTML5 document:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Bookings</title>
</head>
<body>
<header><h1>Book a class</h1></header>
<main>
<form id="booking">
<label>Name <input name="name" required></label>
<label>Time
<select name="time">
<option>18:00</option>
<option>19:00</option>
</select>
</label>
<button type="submit">Book</button>
</form>
</main>
</body>
</html>Note the semantic tags (header, main), the
Two habits separate amateurs from pros here. First, use semantic elements (header, nav, main, section, article, footer) so the document is meaningful and accessible. Second, always label form inputs — wrap them in a <label> or use for= — so screen readers and taps work.
<div>, and beginners do. But a page that is all divs is invisible to assistive tech and harder to style and maintain. Reach for the semantic element first; fall back to <div> only when nothing fits.Why wrap an in a
Tap an answer to check it — instant feedback, nothing graded.
…
. Most have an opening and closing tag.When the browser parses your HTML, it builds the DOM: a tree of objects, one per element, that JavaScript can read and change at runtime. The HTML is the blueprint; the DOM is the living building.
This matters because all interactivity is DOM manipulation. Later, JavaScript will select nodes, read their .value, change their text, add/remove them, and listen for events on them. A tiny preview:
const form = document.getElementById("booking");
form.addEventListener("submit", (e) => {
e.preventDefault(); // stop the full-page reload
const name = form.name.value; // read a field
console.log("Booking for", name); // do something with it
});Selecting a node, listening for an event, and reading a value — the heart of front-end code.
The DOM is best described as…
Tap an answer to check it — instant feedback, nothing graded.
Tap an answer to check it instantly. Graded scoring, the 80% gate, and saving are in the browser app.
1. In HTTP, which method should read data without changing anything on the server?
Tap an answer to check it — instant feedback, nothing graded.
2. A request for a resource whose ID does not exist should return…
Tap an answer to check it — instant feedback, nothing graded.
3. DNS is responsible for…
Tap an answer to check it — instant feedback, nothing graded.
4. Which is an example of semantic HTML?