When you click "Log in" or open a list of orders, the page doesn't store that data itself — it asks the server. This "question and answer" exchange is the foundation of almost every application, and it's important for a tester to understand how it works: where things break and how to see it.

Let's cover three things: what a client and server are, what protocol they use to communicate (HTTP/HTTPS), and what a request and response are made of. This is the foundation on which DevTools and API testing rest.

Client and server

A client is what a person uses: a browser, a mobile app. It shows the interface and sends requests. A server is a computer somewhere in a data center that stores data (users, orders) and responds to client requests.

An analogy: the client is a guest at a café, the server is the kitchen. The guest places an order (request), the kitchen prepares it and sends it out (response). The guest doesn't go into the kitchen — they communicate through a clear protocol: "order — delivery."

Why this matters for a tester: a bug can be on the client (the page sent the wrong thing, or displayed the response incorrectly) or on the server (it processed something wrong, returned an error). Understanding this split helps you figure out where to look, and write a more precise bug report.

HTTP and HTTPS

HTTP (HyperText Transfer Protocol) is the language client and server use to communicate: how to format a request, how to format a response. Every time a page loads something or submits data, an HTTP exchange happens.

HTTPS is the same thing, but encrypted (the S stands for secure). Data between client and server travels in a protected form; it can't be intercepted and read in transit. A proper website today always uses HTTPS; if a site uses plain HTTP, the browser marks it as "not secure." That's also something to check — that important pages (payment, login) use HTTPS.

Request: what it's made of

Every client request to a server has several parts:

  • Method — what we want to do. The main ones: GET (retrieve data — "show me the orders"), POST (create — "place an order"), PUT/PATCH (update), DELETE (delete).
  • URL (address) — where we're sending the request, for example example.com/api/orders.
  • Headers — metadata: data format, who we are (an authorization token), language.
  • Body — the data we're sending (typically for POST), usually in JSON format.

JSON is a simple text format of "key: value" pairs that clients and servers use to exchange data:

{ "email": "anna@example.com", "amount": 1500 }

It reads almost like a plain list: email is this, amount is that.

Response: what it's made of

The server responds, and for a tester the most important parts are:

  • Status code — a short numeric summary of the request. They group into ranges:
    • 2xx (200, 201) — success, everything is fine.
    • 3xx (301, 302) — redirect to another address.
    • 4xx (400, 401, 403, 404) — a client-side error: bad request, not authorized, access denied, not found.
    • 5xx (500, 503) — a server-side error. Almost always a bug.
  • Response body — the actual data (usually JSON): a list of orders, a created object, an error message.

You need to know status code groups by heart: seeing 404 you immediately know "not found," and 500 means "the server broke" — and you know which direction to dig.

Where this applies

This model sits beneath every action in an application. A form "silently" didn't save — you open the Network tab and check: did the request go out? what method and URL? what status code did the response have? If it's 500 — the bug is on the server, and that's valuable for the report. If the request never went out — the problem is on the client. And to check requests directly, trying out different variations, Postman is the convenient tool of choice — API testing in Postman.

Where beginners stumble:

  • Not telling where things broke. "It doesn't work" — but Network would have shown: the client sent bad data, or the server responded with 500.
  • Not knowing status codes. At minimum, 2xx/4xx/5xx — you need to understand those groups; they immediately tell you where to look.
  • Ignoring HTTPS. Important pages (payment, login) must use the secure protocol — that's a check too.

What to learn next. Now that you understand how a page talks to a server, apply this knowledge in practice: watch the exchange in DevTools and test requests by hand in Postman.