Сеть и HTTP
Всё общение фронтенда с бэкендом идёт по HTTP — текстовому (по смыслу) протоколу «запрос-ответ» поверх TCP. На нём стоят REST API, поверх него договариваются CORS о межсайтовых запросах, а WebSocket отходит от модели «запрос-ответ» к постоянному двустороннему каналу.
Сквозная идея темы — модель запрос/ответ и её ограничения. HTTP по природе безсостоятелен и однонаправлен: клиент спрашивает, сервер отвечает. Версии протокола ускоряют эту модель (мультиплексирование), REST её структурирует, CORS её защищает, а WebSocket её перерастает. Каждый слой ниже раскрывает один из этих механизмов.
Карта темы
- Протокол HTTP — структура запроса и ответа, методы, статус-коды, заголовки.
- Версии HTTP — HTTP/1.1 против HTTP/2, мультиплексирование и конец domain sharding.
- REST API — архитектурный стиль, ресурсы по URL и отображение CRUD на методы.
- Стиль REST — ограничения REST, идемпотентность, уровни зрелости и HATEOAS.
- CORS — простой против предварительного запроса и почему доступ даёт сервер.
- WebSocket — постоянный двусторонний канал, upgrade, аутентификация и переподключение.
Частые ошибки и ловушки
| Ошибка | Последствие |
|---|---|
| Думать, что CORS блокирует браузер «сам» | Доступ разрешает сервер заголовком Access-Control-Allow-Origin; браузер лишь исполняет |
Считать GET подходящим для изменения данных | GET должен быть безопасным и идемпотентным; изменения — через POST/PUT/PATCH/DELETE |
Путать PUT и PATCH | PUT заменяет ресурс целиком (идемпотентен), PATCH меняет часть |
| Считать REST протоколом | REST — архитектурный стиль поверх HTTP, а не стандарт и не протокол |
| Открывать WebSocket там, где хватило бы одного запроса | Постоянный канал оправдан лишь при частом двустороннем обмене |
Пытаться поставить Authorization в браузерный WebSocket | Клиентский WebSocket API не даёт кастомных заголовков — аутентификация на handshake |
| Переподключать WebSocket фиксированным интервалом | Тысячи клиентов ударят по серверу разом; нужен экспоненциальный backoff с jitter |
Значение для собеседований
Сеть спрашивают, чтобы проверить, понимаете ли вы, что происходит между fetch и ответом. Кандидат, который говорит «CORS — это разрешение сервера, а не запрет браузера», сразу показывает, что отлаживал реальные межсайтовые запросы, а не гуглил «как отключить CORS».
Что обычно проверяют:
- Структуру запроса и ответа, смысл методов и статус-кодов.
- Что дал HTTP/2 — мультиплексирование и почему domain sharding больше не нужен.
- Отображение CRUD на методы и разницу
PUT/PATCH. - Кто и как разрешает межсайтовый доступ в CORS, что такое preflight.
- Чем WebSocket отличается от HTTP и как его аутентифицировать.
Типичный неверный ответ: «CORS нужно отключить на фронтенде». CORS вообще не настраивается на клиенте — межсайтовое чтение разрешает сервер заголовком Access-Control-Allow-Origin; браузер лишь применяет это решение.