Роли клиента и сервера
Роли клиента и сервера
Введение
Клиент и сервер — не просто два компьютера, которые переписываются. У каждого из них чётко определённые обязанности. Понимание этих обязанностей поможет тебе как тестировщику быстро определять, на чьей стороне возник дефект.
Что делает клиент
Клиент отвечает за всё, что видит и делает пользователь:
- Отрисовка интерфейса — показывает кнопки, поля, таблицы, картинки
- Сбор пользовательского ввода — обрабатывает нажатия, текст в полях, клики
- Отправка API-запросов — когда пользователь нажимает "Сохранить", клиент отправляет запрос на сервер
- Отображение ответов — получив данные от сервера, показывает их пользователю
- Локальная валидация — проверяет формы до отправки (например, "поле не может быть пустым")
Важно: клиентская валидация — это удобство, а не безопасность. Её всегда можно обойти.
Что делает сервер
Сервер — это "мозг" приложения:
- Валидация входных данных — проверяет, что пришло от клиента (и не доверяет этому слепо)
- Выполнение бизнес-логики — считает цены, применяет скидки, проверяет права доступа
- Обращение к базе данных — читает и записывает данные
- Возврат результата — отправляет клиенту ответ: данные или сообщение об ошибке
- Авторизация — решает, имеет ли этот пользователь право делать то, что он просит
Сервер тоже может быть клиентом
Это важная концепция! В современных приложениях один сервис часто вызывает другой:
Твой браузер → Сервер А → Сервер Б (платёжный шлюз)
→ Сервер В (сервис уведомлений)
→ Сервер Г (сервис аналитики)
Сервер А здесь — одновременно сервер (для браузера) и клиент (для Б, В, Г). Это называется микросервисная архитектура.
Для тестировщика это означает: баг может быть не в "твоём" сервере, а в стороннем сервисе, который он вызывает.
Stateless vs Stateful серверы
Stateless (без состояния): Сервер не помнит предыдущих запросов. Каждый запрос должен содержать всю необходимую информацию (например, токен авторизации).
Запрос 1: GET /profile + токен → сервер проверил токен → вернул профиль
Запрос 2: GET /orders + токен → сервер снова проверил токен → вернул заказы
Stateful (с состоянием): Сервер помнит контекст (например, хранит сессию в памяти).
Большинство современных REST API — stateless. Это важно знать, потому что баги с авторизацией часто связаны именно с тем, что токен не передаётся или передаётся неверно.
Что может пойти не так: клиент vs сервер
Это поможет тебе писать точные баг-репорты:
| Проблема | Чья сторона |
|---|---|
| Кнопка не нажимается / криво отображается | Клиент (frontend) |
| Форма не валидирует поле | Клиент (но проверь и сервер!) |
| Данные не сохраняются в базу | Сервер (backend) |
| Ответ приходит, но данные неверные | Сервер или база данных |
| Страница долго грузится | Может быть и клиент, и сервер, и сеть |
| 500 Internal Server Error | Точно сервер |
| Некорректный JSON в ответе | Сервер |
Типичные ошибки в понимании
- "Валидация на клиенте достаточна" — нет, сервер ВСЕГДА должен валидировать сам
- "500 ошибка — это баг клиента" — нет, 5xx всегда означает проблему на сервере
- "Сервер — это один компьютер" — в реальности может быть несколько серверов за балансировщиком
Что мы запомним
- Клиент отвечает за UI, ввод пользователя и отображение результатов
- Сервер отвечает за логику, валидацию (настоящую!), данные и безопасность
- Сервер сам может быть клиентом по отношению к другим сервисам
- Stateless сервер не помнит предыдущих запросов — каждый запрос самодостаточен
- Определение стороны ошибки помогает писать точные и полезные баг-репорты