Request and response
Most of what a page displays arrives over the network: the page requests data from the server, the server responds. This pair — the request and the response — is the main object of analysis when testing a web application.
On this page
Client, server and frontend
The client is the program a person uses to open the application — most often a browser. The visible part running in the browser is called the frontend: it displays buttons and forms, reacts to clicks and asks for data.
The server, or backend, is a program running on another computer. It receives requests, checks permissions and data, works with a database or other services, then prepares a response. The browser does not connect directly to the database or see the server code.
What happens after an action
For example, someone opens a product list:
1. The browser sends GET /api/products to the server.
2. The server retrieves the products, often from a database.
3. It returns an HTTP response, for example 200 OK and a JSON list.
4. The frontend reads the response and draws product cards on the page.
If the cards are missing, the defect can be at any step: no request was sent, the server returned an error or wrong data, or the frontend did not display correct data. The Network tab in DevTools makes this chain visible. The cards that follow go through it in more detail.
What HTTP means
HTTP stands for HyperText Transfer Protocol. It is a shared set of rules for how a client and a server exchange messages: what a request and response contain, and how a result is described with a status code. HTTP is stateless: each request is independent, so a server does not automatically remember the previous one. Cookies and authorization tokens in headers tell it who made the request. HTTPS is HTTP over an encrypted connection; this is what normal websites use.
Parts of a request
- Method — the action requested:GET — read.POST — create.PUT and PATCH — modify.DELETE — remove.
- URL — the address the request is sent to. It can be made up of the site address, the path to the resource and query parameters:https://shop.example.com/products?city=tallinnhttps://shop.example.com — the site address;/products — the path to the resource;?city=tallinn — a query parameter, which passes an additional condition for the request.
- Headers — technical information sent alongside the request: the content type or an authorization token, for example.Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
- Request body — the payload the client passes to the server. Usually JSON data for creating or modifying a resource. A GET request normally has no body; POST is the method normally used to send one when a resource is created.{"name": "Sneakers","price": 79.99}
What JSON is
JSON — JavaScript Object Notation — is the text format a client and a server use to pass data to each other. It is meant to be read by a program, but a person can read it too, which is what makes a response body worth opening.
Data is written as key–value pairs. The key is always in double quotes, pairs are separated by commas, and the whole thing sits in curly braces — that is an object:
{
"id": 12,
"name": "Sneakers",
"price": 79.99,
"inStock": true,
"discount": null
}
The value tells you its own type: a string is in double quotes, a number is not, true and false are booleans, and null means there is no value. The difference matters — a price that arrives as the string "79.99" instead of the number 79.99 is a defect, even though the page may well display it correctly.
Square brackets hold an array — a list of values, often a list of objects. Objects nest inside one another, which is how related data travels together:
{
"city": "Tallinn",
"products": [
{ "id": 12, "name": "Sneakers" },
{ "id": 15, "name": "Boots" }
]
}
In Network the raw body is under Response, and Preview shows the same data laid out, where nested objects can be unfolded. Two cases that look identical on screen are different here: an empty list arrives as [], a missing value as null — and the page shows “nothing” for both.
Request methods
The method tells the server what to do with the resource. The same address with a different method means a different action.
- GET — read data, and change nothing: GET /api/products?city=tallinn returns a list of products. The parameters travel in the address and the request normally has no body.
- POST — create: POST /api/orders with a JSON body creates a new order.
- PUT — replace the whole resource: PUT /api/products/12 with a complete body. Any field missing from that body is a field the resource loses.
- PATCH — change a part of it: PATCH /api/products/12 with the body {"price": 79.99} changes the price and nothing else.
- DELETE — remove: DELETE /api/products/12.
Repeating a request does not mean the same thing for every method. GET, PUT and DELETE leave the system in the same state however many times they are sent: product 12 can only be deleted once. A repeated POST normally creates another record — which is where two identical orders after a double click come from.
What a tester checks: that the method in Network → Headers matches the action on screen. A search or a filter sent as a GET can be bookmarked and passed on as a link; the same search over POST cannot. Data changed or removed by a GET is worth a defect report.
Path and query parameters
Both pass information in the URL, but in different places. A path parameter is part of the route that identifies a resource: in /sections/3, 3 identifies a section. A query parameter comes after ? and usually filters, sorts or configures the response: in /sections/3?language=en&page=2, language and page are query parameters. In Network, the full URL is visible in Headers; query parameters are also grouped in Payload.
Parts of a response
A status code, its own headers and a body containing the data the page then renders. A discrepancy between what the page displays and what the response body contains localises the defect: either the data was correct and the page rendered it incorrectly, or the data was already incorrect.
Status codes: four groups
The first digit defines the group a status code belongs to:
- 2xx — success.
- 3xx — redirect.
- 4xx — an error in the request.
- 5xx — an error on the server.
The group indicates which side the defect belongs to: 4xx usually means the page sent incorrect data, 5xx means the backend failed on a valid request.
Codes encountered most often
- 200 OK — the response contains a body. 201 Created — a resource was created, usually after a POST. 204 No Content — the operation succeeded and returns no data.
- 301 and 302 — permanent and temporary redirects. 304 Not Modified — the resource has not changed and the browser uses its cached copy. This is normal behaviour, not an error.
- 400 Bad Request — the server could not parse the request. 422 — the request was parsed and the data failed validation; form defects usually produce this code.
- 401 Unauthorized — the user is not authenticated. 403 Forbidden — the user is authenticated but lacks the required permissions.
- 404 Not Found — there is no resource at this address; the server itself is operational. 409 Conflict — the request conflicts with the current state, for example registration with an email that is already in use.
- 429 Too Many Requests — a rate limit was reached.
- 500 Internal Server Error — an unhandled error on the backend. 502 Bad Gateway and 504 Gateway Timeout — the proxy could not reach the service behind it or did not receive a response in time. 503 Service Unavailable — the service is unavailable or overloaded, often during a deployment.
Do Not Look at Status Alone
An HTTP status shows how the server handled a request at the protocol level.
For example, 200 OK means the server received the request and returned a response without an HTTP error. The response can still be wrong from the application’s point of view.
Imagine that you request a list of orders. In Network, the status is 200, but the list on the page is empty.
Open Response to see what came back from the server. It might contain:
- an empty array [];
- the wrong total;
- outdated data;
- an object for a different user;
- "success": false;
- an error sent inside the response body.
So a status alone is not enough.
After checking Status, look at Response and make sure the server returned exactly the data you expected.
200 + correct data in Response, but nothing on the page → the problem is most likely in processing or displaying the response on the client.
200 + incorrect data in Response → the problem happened earlier, before the page tried to display the data.
At the interview
What is usually asked for is not a memorised definition but reasoning about a specific request. Try answering before opening the answer.
juniorentry-level knowledge
1. What does an HTTP request consist of?
A method, a URL, headers and, where needed, a body. A POST request, for example, may send JSON in the body while the headers carry the content type and an authorization token.
2. What is the difference between the 401 and 403 response codes?
401 Unauthorized means the user is not authenticated: not signed in, or holding a token that is no longer valid. 403 Forbidden means the user is identified but has no permission for this action.
3. What do 4xx and 5xx statuses usually indicate?
4xx usually points to a problem in the request: wrong data, missing authentication or permissions, an address that does not exist. 5xx means the server failed to process a valid request. It is a direction for localisation, not a final diagnosis.
4. What is the difference between GET and POST?
GET asks for data and must not change it: the parameters travel in the address, the request normally has no body, and the link can be bookmarked or passed on. POST sends data to the server in the request body — usually to create something — and sending it again normally creates another record.
5. What is the difference between PUT and PATCH?
PUT replaces the whole resource: the body carries the complete set of fields, and whatever is missing from it the resource loses. PATCH changes only the fields it carries — a body of {"price": 79.99}, for instance, changes the price of a product and touches nothing else.
middlea more advanced level
6. Is a 200 enough to call a response correct?
No. 200 OK confirms the HTTP request was processed, but Response may still carry empty, stale or someone else's data, or a logical error inside the body. The body has to be compared with the expected result.
7. The page shows no orders although the request returned 200. How do you investigate?
Open the response body. If the correct list of orders is there, the problem is most likely in how the frontend processes or displays the data. If the list is already empty or wrong, the defect occurred earlier — in the data, in the request or on the server.
8. A user clicked “Place order” twice and got two orders. What does the Network tab show?
Two identical POST requests, both with a 2xx status: the server dutifully created two records. A repeated POST is supposed to behave that way — unlike PUT and DELETE, where repeating leaves the system as it was. So the request itself is not the defect: there is no protection against a double submission, neither a disabled button nor a check on the server. Both requests and both responses go into the report.
Questions on the other topics are collected on the QA interview questions on DevTools page.