A web request is a protocol-formatted message, usually an HTTP request, created by a client and transported as bytes through operating system and network layers to a server process that can interpret it and produce a response.
Learning Question
When a browser sends a request to a server, what is actually being sent, and what is actually running?
It is easy to say, “the frontend calls the backend.” That phrase is useful in everyday programming, but it hides the real boundary.
The browser does not call a server function the way one local function calls another local function. The browser creates or asks the operating system to send a network message. That message crosses process and machine boundaries. The server-side function runs only after a server process receives the message, parses it, matches it to application code, and invokes the relevant handler inside the server process.
The first mental model is:
Sending a web request means sending a structured message across a network boundary, not jumping into server code.
Local Function Call vs. Network Request
A local function call happens inside one running process.
When code calls a local function, the caller and callee share the same process memory and execution environment. The call can pass values through the language runtime, use the call stack, return directly to the caller, and access in-process data according to the language’s rules.
A network request is different.
| Local Function Call | Network Request |
|---|---|
| Happens inside one process | Crosses process and often machine boundaries |
| Uses the language runtime and call stack | Uses protocol messages, sockets, operating system networking, and network transport |
| Passes values directly as runtime objects | Sends bytes formatted according to a protocol |
| Returns by normal function return | Produces a response message that must travel back |
| Can access in-process memory | Cannot access remote process memory directly |
This distinction matters because many web confusions come from using function-call language too literally.
When client code runs this kind of operation:
fetch("/api/items")the browser is not executing the server’s /api/items handler directly.
The browser is creating an HTTP request for /api/items, sending it through the operating system and network, and waiting for a response. The server process may later decide that this request maps to a particular route handler, but that handler runs on the server machine, inside the server process.
Participants in a Web Request
A web request path has several participants. They are easy to collapse into one phrase, but they play different roles.
| Participant | Role |
|---|---|
| User action | Starts the visible cause, such as clicking a button, submitting a form, or loading a page. |
| Browser or client | Creates the request intent, formats an HTTP request, enforces client-side rules, and receives the response. |
| Operating system | Provides networking APIs, sockets, DNS integration, TCP/IP behavior, TLS support through libraries or system facilities, and access to network hardware. |
| Network | Carries packets between machines through local networks, routers, internet service providers, and other infrastructure. |
| Server machine | Receives incoming network traffic addressed to it and runs server-side processes. |
| Server process | Listens for connections or receives requests through a server stack, parses incoming data, and dispatches work to application code. |
| Application code | Implements the actual server-side behavior, such as reading request data, validating input, querying a database, changing state, and building a response. |
These participants are not interchangeable.
The user action does not run the server code.
The browser does not directly use the server’s memory.
The network does not understand the application meaning of the request.
The server machine is not the same thing as the server application.
The application code does not run until the server-side execution path reaches it.
What Is Sent
What is sent across the network is bytes.
Those bytes are not random. They encode a protocol-formatted message. For normal web application traffic, the relevant application-level protocol is HTTP.
An HTTP request contains structured information such as:
- a method, such as
GET,POST,PUT, orDELETE - a target, such as a path and query string
- headers, such as
Host,Content-Type,Accept, orCookie - an optional body, such as JSON, form data, or uploaded file data
At the HTTP level, a request might conceptually mean:
GET /api/items HTTP/1.1
Host: example.com
Accept: application/jsonReal browsers and servers may use HTTP/2 or HTTP/3, where the wire representation is not the same textual shape as HTTP/1.1. The durable point is not the exact syntax. The durable point is that the client sends a structured HTTP request message, and lower layers carry the bytes that represent that message.
The Important Boundaries
A web request crosses boundaries that a local function call does not cross.
The browser does not magically invoke a server function.
It cannot directly jump into server-side call stacks.
It cannot directly read or write server memory.
It cannot directly query the server’s database just because the page has a button or a form.
It cannot directly skip the server process and run application code.
The client can only send a message to an address and port using agreed protocols. The server process decides whether it is listening, whether the message is valid, which application handler should receive it, whether the request is authorized, and what response should be returned.
This boundary is a security boundary, an execution boundary, and a responsibility boundary.
Simple End-to-End Flow
A simplified request flow looks like this:
user clicks button
-> browser event handler or built-in browser behavior decides to send a request
-> browser builds an HTTP request
-> operating system and networking stack send request bytes
-> network carries packets toward the server machine
-> server machine receives bytes addressed to its network interface
-> server process reads and parses the request
-> server framework routes the request to application code
-> application code handles the request
-> application code or framework builds an HTTP response
-> response bytes travel back through the network
-> browser receives and interprets the response
-> page code or browser behavior updates what the user seesThis flow is simplified. Later chapters will separate request construction, DNS, connection setup, TCP, TLS, server listening, routing, middleware, database access, and response handling more carefully.
For now, the important point is that the request exists as a message moving through layers before server-side application code runs.
What the Server Actually Receives
The server machine receives network traffic, not a browser event.
The server process receives data from a network connection or request stream, not a JavaScript function call.
The web server or application framework interprets that data as an HTTP request. It may turn the request into convenient objects such as request, headers, body, params, or cookies, but those are server-side representations created after the protocol message arrives.
Application code usually sees a framework-level request object, but that object is not what crossed the network. What crossed the network was encoded data. The request object is the server-side program’s representation of that data.
What Runs on the Client and What Runs on the Server
Client-side code runs in the browser or client runtime.
Server-side code runs in a server process.
They may be written in the same language, share type definitions, or live in the same repository, but they do not run in the same process merely because the project is one application.
When the client sends a request, client-side execution continues according to the browser and JavaScript runtime. The server-side handler, if one is reached, runs separately on the server. The response is another message that lets the client continue its own work with new information.
The request is the communication bridge between two separate execution contexts.
Common Misunderstandings
”The frontend calls the backend function.”
This is a shortcut. More precisely, the frontend asks the browser or client runtime to send an HTTP request. The backend function may run later if the server process receives the request and routes it to that function.
”The request goes straight to my application code.”
It does not. It passes through client networking, network transport, the server operating system, a listening server process, protocol parsing, and usually framework routing before application code handles it.
”The browser directly talks to the database.”
In a typical server-backed web application, it does not. The browser sends a request to server-side code. Server-side code may then query a database using database credentials and network access that the browser does not have.
”The URL is the function being called.”
A URL is an identifier used to build and route a request. Server code may map a URL path to a handler, but the URL itself is not a function call.
”Sending JSON means the server receives a JavaScript object.”
JSON crosses the boundary as text bytes formatted according to JSON rules. The server may parse those bytes into an object in its own runtime, but the runtime object itself is not transmitted.
What This Chapter Does Not Explain Yet
This chapter only defines the basic meaning of sending a web request.
It does not yet explain full HTTP syntax.
It does not yet explain DNS, TCP, TLS, sockets, ports, load balancers, proxies, server frameworks, middleware, database connections, or browser rendering.
Those topics need the first boundary to be clear first:
A web request is a structured message transported between execution contexts.
Core Mental Model
Keep these boundaries separate:
- A user action is an event or browser behavior that may cause a request.
- A browser or client creates a protocol-formatted HTTP request.
- The operating system and network transport bytes; they do not execute application intent.
- The server machine receives network traffic, but server application code runs only inside a server process.
- A server process interprets the incoming message and dispatches it to application code.
- Application code handles the request and creates or contributes to a response.
- The response is another structured message transported back to the client.
The most useful diagnostic question is:
At this step, are we talking about local execution, a protocol message, byte transport, server dispatch, or application logic?
Final Summary
Sending a web request means creating an HTTP request message and transporting its bytes from a client to a server process.
The server response happens because server-side code receives, interprets, routes, and handles that message. It is not caused by the browser directly calling a server function, touching server memory, or accessing the database by itself.