Clients, Servers & the Life of a Request

A client initiates an interaction because it needs a capability; a server waits for interactions and provides that capability. These are roles, not permanent labels for particular machines. A browser is a client of the Task API, while the Task API becomes a client when it opens a PostgreSQL connection. During local development both processes may run on one computer and still communicate through the same network abstractions used in production.

A backend server is normally a long-running process. It binds a socket to an address and port, accepts connections, reads protocol messages, applies rules, and writes responses. An IP address identifies a network interface in a routing context; a port helps the operating system deliver traffic to a listening socket. The pair matters—port 8080 on your laptop is not port 8080 on a remote host.

For http://localhost:8080/tasks, the operating system resolves localhost to a loopback address. The client opens a TCP connection to port 8080, then sends an HTTP request over that connection. With HTTPS, a TLS handshake also authenticates the server and negotiates encryption before protected HTTP data flows. DNS, TCP, TLS, and HTTP fail differently, so naming the stage prevents random code changes.

1
2
3
4
5
6
7
8
9

URL
  -> host resolution
  -> route to an address
  -> TCP connection to a listening socket
  -> optional TLS handshake
  -> HTTP request bytes
  -> server handler
  -> HTTP response bytes
  -> client interpretation

Suppose a browser requests the open tasks. It serializes an HTTP message, sends it through the established connection, and waits. The server parses the request, authenticates the caller when required, validates the contract, invokes the relevant use case, and may read PostgreSQL. It then serializes an HTTP response. The browser does not receive a Java object or a database row; it receives protocol data such as status, headers, and JSON.

1
2
3
4
5
6
7
8

GET /tasks?status=OPEN HTTP/1.1
Host: localhost:8080
Accept: application/json

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

[{"id":42,"title":"Read Module 0","status":"OPEN"}]

The server is authoritative for rules and durable state. A client may disable an invalid button for usability, but the server must still reject an invalid transition because clients can be modified, outdated, automated, or malicious. Presentation state such as an expanded panel belongs naturally to the client; shared task state belongs behind the server boundary.

Timeouts deserve particular care. The server may complete work after the client stops waiting, and the response may be lost after a database commit. That ambiguity is why idempotency, request identifiers, deadlines, and observable logs become important later. A retry is not automatically safe merely because the first response was never seen.

One of the most devastating production incidents is a silent downstream hang: a client connects to a remote TCP socket, sends a request, and waits indefinitely because no read timeout was configured.

1
2
3
4
5
6

# Start a simulated hanging server using netcat that accepts connections but never responds
nc -l 9999

# In another terminal, a client sends HTTP without a timeout:
curl -i http://localhost:9999/tasks
# Terminal hangs forever. In a multi-threaded application, each hanging request consumes 1 thread.

Every production network call needs an end-to-end deadline plus timeouts for the phases the chosen client exposes, such as connection establishment and waiting for a response. Values must come from the caller latency budget and measured downstream behavior; no universal one-to-five-second range fits every workload.

Use the JDK’s static web server or another supplied fixture to create a real listener. From a second terminal, inspect the port and send a request. This isolates networking and HTTP from the framework, database, and application rules. When Spring later listens on the same port, you will recognize the unchanged operating-system boundary.

1
2
3
4
5
6
7
8

mkdir -p /tmp/task-http
printf '[{"id":42,"status":"OPEN"}]\n' > /tmp/task-http/tasks.json
jwebserver -p 8080 -d /tmp/task-http

# Second terminal
curl -i http://localhost:8080/tasks.json
# Linux listener inspection
ss -ltnp 'sport = :8080'

1. 01Predict the response before sending the request.
2. 02Stop the server and repeat the request; record how the failure changes.
3. 03Start it on port 8081 and prove that the old URL still fails.
4. 04Separate facts from guesses: listener, connection, HTTP status, headers, and body.