Request

In short: A request that a client sends to a server to trigger an action or retrieve data — the basis of the request-response pattern of many protocols.

In more detail: In HTTP, for example, a request consists of a method (GET, POST etc.), a path and optionally headers/a body. The server answers every request with a response. This pattern runs through many protocols, not just HTTP.

In Depth

The request-response pattern is one of the most fundamental communication patterns in networking: a client ALWAYS initiates the communication, the server only reacts — the server can’t “just” send a message to a client on its own without the client having asked first (exceptions such as push mechanisms establish their own permanent connection for this). This pattern is deliberately kept simple: it’s easy to predict, easy to debug (every response can be matched unambiguously to its request) and fits well with the “stateless” character of many web protocols.

In HTTP, a request typically contains: a method (GET for retrieving, POST for creating, PUT/PATCH for changing, DELETE for deleting), a path (which resource is meant), headers (metadata such as authentication or the desired response format) and optionally a body (the actual payload, e.g. with POST). Other protocols use the same basic pattern with different details — a DNS request, for example, asks for the IP address of a domain name, while an ICMP echo request (the basis of ping) simply asks “are you reachable?”.

An example request in raw format

This is what a minimal HTTP request looks like “on the wire”, before it’s hidden inside a browser interface or API library:

GET /wiki/07-netzwerktechnik-und-protokolle/tcp HTTP/1.1
Host: emzett-digital.com
Accept: text/html
User-Agent: Mozilla/5.0

The first line names the method, path and protocol version; the following lines are header fields as key-value pairs. In a POST request, the body would additionally follow after a blank line, e.g. as a JSON data structure.

Statelessness as a design principle

An important feature of the HTTP request-response pattern is statelessness: the server handles every request independently of all previous ones and by default “remembers” nothing between two requests. This makes servers easier to scale (every request can be answered by any server in a load-balanced fleet without it having to know the previous history), but requires additional mechanisms such as cookies or auth tokens when an application does need to “remember” a user across several requests (e.g. a logged-in state).

See also: HTTP, Echo Request