Internet & HTTP Essentials

The browser exercises so far could run without an application API. The marketplace cannot: it needs data owned by another process. Before writing more fetch calls, we need a model of the boundary those calls cross.

Internet and web are not synonyms

The Internet connects networks and hosts. The web is one family of applications built on that connectivity, using resource addresses and protocols such as HTTP. Other applications, including database connections, can use networks without being browser HTTP interactions.

In the practice application, the browser makes HTTP requests to the API, while the API uses PostgreSQL’s protocol to talk to the database. Calling both connections “the API call” hides a useful distinction.

From a name to a request

A simplified HTTPS interaction involves resolving a host name, reaching the destination, establishing protected communication, and exchanging HTTP messages. DNS maps names to records such as IP addresses. Ports help distinguish services at an address. TLS provides encryption and server authentication for HTTPS.

Do not interpret the simplified sequence as “every click repeats every step.” Browsers can reuse connections and cache DNS results. HTTP/1.1 and HTTP/2 commonly use TCP; HTTP/3 uses QUIC over UDP with TLS integrated into that transport. This transport detail matters here because HTTP is not tied to one particular transport. See the HTTP overview.

A DNS failure occurs before an HTTP response from the application. It is therefore not an application 404 or 500.

Read a URL deliberately

Consider:

https://catalogue.example.test:8443/rooms/12?day=monday#availability

Here https is the scheme, catalogue.example.test the host, 8443 the explicit port, /rooms/12 the path, day=monday the query, and availability the fragment. The fragment is handled on the client and is not included in the HTTP request target sent to the server.

The .example.test name is illustrative, not a service to visit. Use the practice application for experiments.

An origin combines scheme, host, and effective port. Changing any of these can change the origin. Paths do not distinguish origins. Thus these have different origins:

http://localhost:5173
http://localhost:8000

Even on the same computer, the ports differ. MDN’s origin definition provides the formal terminology.

Inside Compose, api and database are service names resolved on its network. Your host browser does not normally resolve them that way. Conversely, localhost inside a container refers to that container, not your host browser or another service.

An HTTP exchange

A simplified request and response might be:

GET /rooms/12 HTTP/1.1
Host: catalogue.example.test
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"id":12,"name":"Quiet room","capacity":4}

This text illustrates message semantics, not how every HTTP version appears on the wire. HTTP/2 and HTTP/3 use different framing while retaining methods, status codes, headers, and representation data.

The method and target identify what is being requested. Headers carry metadata. A body can carry a representation or submitted data. Accept describes response formats the client can accept; Content-Type describes the format of a message’s body. JSON is a data format, not a transport or authentication mechanism.

The authoritative definition of HTTP semantics is RFC 9110.

Methods communicate intended semantics

A safe method such as GET must not be used as a hidden “place order” or “delete record” action. A request can still create operational side effects such as access logs; safety concerns the action requested by the client.

Idempotency concerns repeating an operation’s intended effect, not guaranteeing byte-for-byte identical responses. Part 3 studies it with state transitions. Do not retry an arbitrary POST after a lost connection on the assumption that the first attempt did nothing.

Status is part of the contract

Do not decode a 204 as JSON. Do not display 404 as “network disconnected.” A network failure might leave you with no HTTP response at all. A server can be reachable and still reject a request.

Part 5 teaches authentication and authorization; recognizing their status vocabulary now does not require implementing them.

Stateless requests and stateful applications

HTTP request semantics do not require the protocol to remember an application conversation between successive requests. That does not mean web applications have no state. Your component has local state, PostgreSQL has durable state, and later sessions associate requests with an identity.

The state must be represented and managed somewhere. A user does not become authenticated merely because the previous page displayed their name.

Trace an unfamiliar exchange

Apply the URL, message, failure-boundary and retry vocabulary together. The sequence uses a different host and application rather than repeating the chapter’s room and todo examples.

Observe the practice application

Open the practice application’s Network panel, reload its home page, then click Load todos. Distinguish the initial document, JavaScript modules, and /api/todos request. Record one response’s method, full URL, status, content type, and body shape. Which request originates from browser application code rather than a database client?

Use a direct API request to compare with the browser observation. A request can succeed in curl while browser access is constrained by origin rules. The next chapter explains CORS; it is not a general replacement for server security.

Check Your Understanding

1. How do the Internet, HTTP, and a JSON API differ?
2. What determines an origin, and why are the practice application’s two localhost ports different origins?
3. Why is a DNS failure not an HTTP status code?
4. What does HTTP statelessness not imply about application state?
5. Why can retrying a POST after a lost response be unsafe?