How the Web Works

Every website and web app is a conversation: the browser asks for something at a URL, and a server sends back a response. To talk to APIs with JavaScript, you need to read that conversation: URL, method, status, headers, and body.

This lesson gives you the map before the first live network request. You will build request-shaped objects and read static Network-tab transcripts, but you will not send data to a server until the next lesson.

URLs name the thing you want

A URL is an address with parts. This one points at a collection of orders and filters it with a query string:

https://api.example.test/orders?status=open&page=2#results

Read it left to right:

• https: is the scheme. It tells the browser what protocol to use.
• api.example.test is the host. It names the server.
• /orders is the path. It names the resource on that server.
• ?status=open&page=2 is the query string. It carries extra key-value options.
• #results is the fragment. It is for the browser side of the page; it is not sent to the server in an HTTP request.

JavaScript has a built-in URL object that can parse those parts without string surgery:

const address = new URL("https://api.example.test/orders?status=open&page=2#results");
 
const parts = [
  address.protocol,
  address.host,
  address.pathname,
  address.searchParams.get("status"),
  address.hash,
];
 
console.log(parts.join(" | "));

→ https: | api.example.test | /orders | open | #results

The query string is not a place for secrets. URLs can appear in browser history, server logs, analytics tools, screenshots, and shared links. Use query strings for normal filters like page number, search term, or sort order.

Requests say what action you want

HTTP is the request/response protocol browsers use for most web traffic. A request is the browser or client asking a server for work. The request has:

• a URL
• an HTTP method
• request headers
• sometimes a request body

The method is the verb of the request. The common first set is small:

• GET asks to read something.
• POST asks to create or submit something.
• PUT asks to replace something.
• PATCH asks to change part of something.
• DELETE asks to remove something.

Those names are a contract between client and server. JavaScript does not make a POST save anything by itself. The server decides what each method means for each URL, then sends a response.

Headers are metadata: small named facts about the request or response. For example, Accept: application/json means the client would like JSON back. Content-Type: application/json means the body being sent is JSON text. The body is the larger payload, such as a JSON object for a new post or form submission.

Responses tell you what happened

A response is the server's answer. It has:

• a numeric status code
• response headers
• often a response body

Status codes are grouped by their first digit:

• 2xx means the request worked. 200 OK is the everyday success.
• 3xx means redirect: the client should look somewhere else.
• 4xx means the client asked for something the server will not or cannot provide. 404 Not Found is the classic missing URL.
• 5xx means the server failed while trying to handle the request.

Do not read a status code as only success or crash. It is part of the server's message. A 404 response is still a response: the server answered, and your code needs to decide what the page should show next. Lesson 16.3 goes deeper on loading, error, timeout, and retry behavior. For now, learn to read the code family and the response body together.

The lifecycle is concrete:

1. The browser builds a request from a URL, method, headers, and optional body.
2. The server receives that request and decides what to do.
3. The server sends back a response with status, headers, and optional body.
4. The browser or your JavaScript reads the response and decides the next UI step.

That last step matters. Servers send information; clients choose the user experience.

Try it — build a request shape

This playground does not call the network. It uses the same browser classes you will meet around real requests: URL, Request, and Headers. Change the method or URL and watch the parsed request update.

The important detail is the boundary: constructing a Request object describes a request. It does not contact the server. In 16.2, you will hand a URL or request-like options to fetch, and then the browser will actually send the request.

Read the Network tab like a book

The DevTools Network tab shows the conversation the browser is already having. Open DevTools, choose Network, reload the page, then select one row.

Start with the row list:

• Name is the file, document, image, script, or API URL being requested.
• Method is usually GET for page assets and API reads.
• Status is the response code.
• Type tells you whether the browser sees a document, script, stylesheet, image, JSON response, and so on.
• Waterfall shows timing: when the request started and how long it took.

Then read the selected request's detail tabs. Headers is the table of contents: Request URL, Request Method, Status Code, Response Headers, and Request Headers. Payload shows data sent by the client for methods like POST. Preview and Response show the response body, often parsed nicely as JSON in Preview and raw text in Response.

A small API request might look like this:

Name: orders?status=open&page=2
Method: GET
Status: 200 OK
Type: application/json
 
Request URL: https://api.example.test/orders?status=open&page=2
Request Method: GET
Status Code: 200 OK
 
Request Headers
Accept: application/json
 
Response Headers
Content-Type: application/json
 
Response
[
  { "id": 101, "status": "open", "total": 42.5 },
  { "id": 102, "status": "open", "total": 18 }
]

That transcript gives you a debugging order. If the URL is wrong, fix the address. If the method is wrong, fix the action. If the status is a 4xx, inspect what the client asked for. If the status is a 5xx, the server failed while handling a request that reached it. If the body is not the shape your code expected, inspect Preview or Response before blaming your rendering code.

APIs are web conversations for programs

An API is a boundary one program exposes so another program can ask it for work. Web APIs often use HTTP: URLs name resources, methods name actions, headers describe formats, and JSON bodies carry data.

You already know JSON from Section 7: it is text that can represent data. That makes it a natural response body for APIs. The next lesson turns this map into live JavaScript: call an API with fetch, wait for the response, then read JSON and render it into the page.