Jan Mikoláš
Glossary
Client and server
A client requests a service; a server provides it and determines its result. These roles do not mean one browser communicating with one physical computer.
Short definition
Roles in communication, not the name of a specific technology.
A client is software that uses a service: most commonly a browser, but also a mobile application, integration service, command-line tool or automated import. A server provides functionality or data, accepts requests and applies the rules of its contract.
Behind one public address there may be DNS, a reverse proxy, multiple application instances, caches and database services. Conversely, one server application can be the client of another API. The designation depends on the direction of the specific communication flow.
The problem it solves
It separates the use of a service from its provision
The client-server model allows the same backend to serve different devices and automated systems.
- a browser and mobile application use the same API
- an internal administration interface, online store and partner read or change data through a defined contract
- a reverse proxy hides the internal topology and forwards the request to the correct service
- the server centrally verifies data, identity and permissions instead of trusting the client
- monitoring tracks response status, latency and communication availability
Practical example
Three clients of one order API
A web frontend, mobile application and internal warehouse system can use the same API to retrieve an order. Each client presents or automates it differently, but the server verifies the same tenant, identity and permissions for all of them.
The server returns an HTTP status code, headers and possibly JSON in the response. A 202 response can mean, for example, that the server accepted a job for processing, not that the warehouse synchronisation has already finished.
GET /api/orders/ORD-42 HTTP/1.1
Host: api.example.cz
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{"id":"ORD-42","status":"paid"}How it works
From a URL to a service and back
This simplified flow of one HTTP exchange shows where responsibility boundaries arise.
- The client knows the URL A browser or another program specifies the resource, method, headers and any request body.
- DNS and HTTPS The domain name is resolved to a network destination, while TLS authenticates the server and protects the transport.
- Public entry layer A web server or reverse proxy can route the request, terminate TLS and apply technical limits.
- Application server The backend performs authentication, authorization, validation and business logic over the data.
- Response to the client The server returns a status, metadata and content. The client decides how to display or automatically process the result.
Important concepts
The client, server and intermediary have different roles.
Distinguishing them helps design trust, errors and operational boundaries correctly.
Request and response
The client initiates the request; the response describes the result. Their precise meaning is defined by HTTP and the contract of the service.
User agent
A program acting on behalf of a user, often a browser. A user and a client are not the same concept, however.
Server as software and infrastructure
It may mean an application that provides a service or, more loosely, the infrastructure where it runs. Context determines the meaning.
Proxy
An intermediary can forward traffic, cache or route requests. A server application should trust forwarding headers only from a known proxy.
Stateless HTTP
HTTP does not retain the user between requests by itself. An application can use a cookie, session or token, but each request must be evaluated securely.
Benefits and limitations
Network communication enables sharing but also introduces uncertainty.
Benefits
- the same service can serve the web, a mobile client and an integration
- a clear contract separates the client interface from the service implementation
- infrastructure can scale and protect the entry boundary independently of the client
- standard HTTP tools make caching, monitoring and troubleshooting easier
Common mistakes
- trusting a role, price or tenant value supplied by the client
- assuming that a response means all asynchronous consequences have completed
- treating a server as one physical machine
- retrying a mutation after a timeout without idempotency and a service contract
When it makes sense
It is the fundamental model of both the web and system integrations.
The client-server model is useful whenever one side uses the capabilities of the other, from loading a page to handing an order to a carrier. It helps distinguish where untrusted input originates and where an authoritative decision must be made.
Other communication models exist for some scenarios, such as message queues or peer-to-peer. Even then, a component often acts as a client of one service and a server for another part of the system at the same time.
What to consider
The network is fallible, and the client is not trusted.
A good design accounts for outages, delays and modified requests.
- validate and authorize data on the server, not only in the browser
- use HTTPS and verify trusted proxies correctly
- describe statuses, errors, timeouts and retries in the API contract
- do not infer completion of a business process from an accepted request alone
- log correlation information without sensitive tokens or personal data
Common questions
Common misconceptions about clients and servers
Is a browser always a client?
In traditional web communication, yes. A client can also be a mobile application, cron job, Postman or another server-side service.
Is a database a server?
In the database protocol, the database service has the server role. In a web architecture, however, it is usually a dependency of the application server rather than an HTTP server for users.
Is a reverse proxy a backend?
It is an infrastructure intermediary. It can be part of the operational whole but does not usually contain application domain logic.
Can a server send data without a request?
Traditional HTTP is request-response. SSE begins with a client request, while WebSocket switches to a more bidirectional communication model.
How I work with APIs in practice
I design communication between systems as a clear contract.
For e-commerce and integrations, I address clients, APIs, idempotency, errors and operational behaviour so that communication remains traceable even during outages.