Client-server and REST

Client and server: who is responsible for what

The client asks, and the server decides and responds. The client is a browser, a mobile application or Postman. The server holds the business logic and access to the database; the client never goes into the database directly.

The path of one request when a user pressed "Transfer" in a banking application:

DNS turns the domain into the server's IP address.
A TCP connection and TLS encryption (HTTPS) are established.
The client sends an HTTP request: POST /api/transfers with a token and a JSON body.
A load balancer or an API Gateway passes the request to one of the server instances.
The server checks authorisation, validates the data and runs the business logic: whether there are enough funds, whether limits are exceeded.
The server reads and writes to the database within a transaction.
The server returns a response: status 201, headers, JSON with the transfer id.
The client shows the result to the user.

For a tester it is important that each step can have its own problem: DNS or a certificate on the test environment, a balancer that leads to an old instance, business logic or a transaction that wrote half the data. When I understand this path, it is easier for me to localise a bug and describe it correctly in a report.

In an interview: The client sends an HTTP request, the server checks authorisation, validates the data, runs the business logic, works with the database in a transaction and returns a response with a status. The client doesn't go to the database directly, everything goes through the API.

Three ideas that get asked in interviews

HTTP is stateless. Each request is independent, and the server doesn't remember the previous one. So a token or a cookie is passed in every request. For tests this means any request can be reproduced separately if it has all the needed headers.

Validation on the client is convenience, on the server it is security. A UI form can be bypassed by sending a request directly from Postman or curl. If the server trusts only the front end, you can pass a negative amount or someone else's id. That is exactly why the API is tested separately from the UI, not only through the interface.

Where to look for a bug. The logic is simple:

A wrong request in DevTools: a front-end bug.
A right request but a wrong response: a backend bug.
A right response but wrong display: the front end again.

I use this algorithm every day: I open the Network tab, find the needed request and see at which stage the data became wrong. That way a bug goes to the right team right away.

In an interview: HTTP is stateless, so authorisation goes in every request. Server-side validation is mandatory, because the client can be bypassed, and that is the main reason to test the API separately from the UI.

REST and alternatives

REST is a style of building an API where data are resources at URLs (/users/42), and actions on them are set with HTTP methods: GET reads, POST creates, PUT and PATCH change, DELETE removes. REST is stateless, data is usually passed in JSON, and the result is described with a status code.

Alternatives worth knowing:

GraphQL: one endpoint, and the client itself describes which fields it needs.
SOAP: XML and a strict contract (WSDL), often found in old banking systems.
WebSocket: a persistent two-way connection, for example for quotes or a real-time chat.

For QA the choice of style changes the approach to testing. In REST I check methods, status codes and resources. In GraphQL the status is often 200 even on an error, and you must check the errors array in the body. In SOAP conformance to the XML schema matters, and in WebSocket the order and delivery of messages.

In an interview: REST is an API style where data are resources at URLs and actions are set with HTTP methods; it is stateless and usually works with JSON. If a project is on GraphQL or SOAP, I change my approach to checks, but the principles are the same: contract, validation, authorisation.