Сеть и HTTP
Сетевое взаимодействие для фронтенд-инженеров — модель запрос/ответ HTTP, мультиплексирование HTTP/2 и проектирование REST API.
8 вопросов
JuniorТеорияОчень частоЧто такое REST и как операции CRUD ложатся на HTTP-методы?
Что такое REST и как операции CRUD ложатся на HTTP-методы?
REST — это архитектурный стиль для клиент-серверных API, а не протокол или стандарт: ресурсы обозначаются URL и изменяются через единый набор HTTP-методов. Операции CRUD ложатся на методы так: create → POST, read → GET, update → PUT/PATCH, delete → DELETE.
Типичные ошибки
- ✗Называть REST протоколом или стандартом, а не архитектурным стилем
- ✗Использовать
GETдля изменения данных илиPOSTдля каждой операции - ✗Думать, что REST требует JSON, а не независим от формата
Уточняющие вопросы
- →Почему отсутствие состояния — ключевое ограничение стиля REST?
- →Когда вы выберете
PATCHвместоPUTдля обновления?
JuniorТеорияЧастоКакова структура HTTP-запроса и ответа?
Какова структура HTTP-запроса и ответа?
У запроса есть стартовая строка (метод вроде GET/POST, путь, версия), заголовки (метаданные «ключ–значение», например Host, Content-Type, Authorization), пустая строка и необязательное тело. У ответа есть строка статуса (версия, код статуса вроде 200/404, фраза), заголовки (Content-Type, Set-Cookie, Cache-Control), пустая строка и тело. Метод выражает намерение; код статуса — исход.
Типичные ошибки
- ✗Думать, что
GET-запросы несут тело или что тело обязательно - ✗Путать метод запроса с кодом статуса ответа
- ✗Считать, что заголовки есть только у ответов, а не у запросов
Уточняющие вопросы
- →Что означают классы кодов статуса
2xx,3xx,4xxи5xx? - →Почему
GETсчитается безопасным и идемпотентным, аPOST— нет?
JuniorТеорияЧастоЧто такое WebSocket и чем его соединение отличается от HTTP?
Что такое WebSocket и чем его соединение отличается от HTTP?
WebSocket — это протокол, дающий постоянный полнодуплексный канал поверх одного TCP-соединения, так что клиент и сервер могут слать сообщения друг другу в любой момент. Он открывается как HTTP-запрос с заголовком Upgrade: websocket; после принятия уходит от модели запрос/ответ.
Типичные ошибки
- ✗Думать, что WebSocket полудуплексный или работает по модели запрос/ответ, как HTTP
- ✗Забывать, что он начинается с HTTP-рукопожатия (upgrade)
- ✗Считать, что каждое сообщение открывает новое соединение, а не переиспользует одно
Уточняющие вопросы
- →Почему рукопожатие WebSocket переиспользует механизм HTTP
Upgrade? - →Когда обычный HTTP-опрос предпочтительнее WebSocket?
MiddleТеорияЧастоВ CORS чём разница между простым запросом и запросом с preflight?
В CORS чём разница между простым запросом и запросом с preflight?
Простой запрос (GET/POST/HEAD только с разрешёнными заголовками и типами контента) шлётся прямо на сервер; затем браузер проверяет заголовок ответа Access-Control-Allow-Origin, прежде чем отдать тело скрипту. Доступ к другому источнику в итоге даёт сервер, а не браузер.
Типичные ошибки
- ✗Думать, что доступ к другому источнику решает браузер, а не сервер
- ✗Ожидать, что
PUTили запрос с кастомным заголовком пропустит preflightOPTIONS - ✗Считать, что
Access-Control-Allow-Originшлёт клиент
Уточняющие вопросы
- →Что именно превращает запрос из простого в требующий preflight?
- →Как сервер может кэшировать результат preflight, чтобы не повторять
OPTIONS?
MiddleТеорияИногдаЧем HTTP/2 отличается от HTTP/1.1 и в чём польза для фронтенда?
Чем HTTP/2 отличается от HTTP/1.1 и в чём польза для фронтенда?
HTTP/2 использует бинарный слой фрейминга и мультиплексирует множество одновременных запросов и ответов по одному TCP-соединению, убирая блокировку начала очереди уровня приложения у HTTP/1.1 и лимит ~6 соединений. Он также сжимает заголовки (HPACK). Поэтому старые обходные приёмы вроде domain sharding теряют смысл.
Типичные ошибки
- ✗Думать, что HTTP/2 открывает больше соединений, а не мультиплексирует по одному
- ✗Продолжать использовать domain sharding или склейку файлов под HTTP/2
- ✗Считать, что HTTP/2 меняет транспорт с TCP на UDP
Уточняющие вопросы
- →Почему мультиплексирование убирает блокировку начала очереди на соединение у HTTP/1.1?
- →Почему domain sharding становится анти-паттерном под HTTP/2?
MiddleДизайнИногдаБраузерное приложение полагается на WebSocket для живых обновлений, но соединения рвутся на нестабильных мобильных сетях, при перезапусках сервера и idle-таймаутах. Спроектируйте стратегию переподключения на клиенте: как обнаружить разрыв, как решить, когда повторять, как не перегрузить сервер, когда множество клиентов переподключаются разом, и как восстановить состояние приложения после успешного переподключения. Отметьте пределы наивного повтора с фиксированным интервалом.
Браузерное приложение полагается на WebSocket для живых обновлений, но соединения рвутся на нестабильных мобильных сетях, при перезапусках сервера и idle-таймаутах. Спроектируйте стратегию переподключения на клиенте: как обнаружить разрыв, как решить, когда повторять, как не перегрузить сервер, когда множество клиентов переподключаются разом, и как восстановить состояние приложения после успешного переподключения. Отметьте пределы наивного повтора с фиксированным интервалом.
Слушайте событие close/error и запускайте цикл переподключения. Используйте экспоненциальный backoff с потолком (1с, 2с, 4с … до 30с) плюс jitter, чтобы тысячи клиентов не переподключались синхронно и не устроили лавину на сервер. Heartbeat-кадры ловят тихо умершее соединение.
Типичные ошибки
- ✗Повторять с фиксированным интервалом, вызывая лавину (thundering herd) на сервере
- ✗Опускать jitter, из-за чего все клиенты переподключаются синхронно
- ✗Забывать переподписаться и ресинхронизировать состояние после переподключения
Уточняющие вопросы
- →Почему добавление случайного jitter к backoff важно, когда множество клиентов рвётся разом?
- →Как id последнего подтверждённого сообщения позволит повторить лишь пропущенное?
SeniorДизайнИногдаВы строите браузерное приложение, открывающее WebSocket к бэкенду, который должен обслуживать только аутентифицированных пользователей. WebSocket API браузера не позволяет задавать произвольные заголовки запроса вроде Authorization, поэтому обычный подход с bearer-токеном в заголовке на клиенте недоступен. Спроектируйте, как вы аутентифицируете и авторизуете WebSocket-соединение: как клиент докажет личность при подключении, как сервер это проверит и как вы обработаете токен, истекающий при долгоживущем открытом соединении. Объясните компромиссы вашего подхода против альтернатив.
Вы строите браузерное приложение, открывающее WebSocket к бэкенду, который должен обслуживать только аутентифицированных пользователей. WebSocket API браузера не позволяет задавать произвольные заголовки запроса вроде Authorization, поэтому обычный подход с bearer-токеном в заголовке на клиенте недоступен. Спроектируйте, как вы аутентифицируете и авторизуете WebSocket-соединение: как клиент докажет личность при подключении, как сервер это проверит и как вы обработаете токен, истекающий при долгоживущем открытом соединении. Объясните компромиссы вашего подхода против альтернатив.
Аутентифицируйте на рукопожатии: сервер, который видит HTTP-запрос upgrade, проверяет существующую session-cookie или короткоживущий токен, переданный через URL соединения (query-параметр) или subprotocol; отклоняйте upgrade при невалидности, чтобы неавторизованные сокеты не открывались.
Типичные ошибки
- ✗Считать, что конструктор WebSocket в браузере может задать заголовок
Authorization - ✗Считать соединение аутентифицированным навсегда и игнорировать истечение токена
- ✗Класть долгоживущий токен в URL, где он утекает в логи сервера
Уточняющие вопросы
- →Почему session-cookie на запросе upgrade уязвима к CSRF без проверки origin?
- →Как вы переавторизуете соединение, чей токен истёк в середине сессии?
SeniorТеорияРедкоЧто такое концепция зрелости REST под названием HATEOAS и что она даёт?
Что такое концепция зрелости REST под названием HATEOAS и что она даёт?
HATEOAS (Hypermedia As The Engine Of Application State) — высший уровень зрелости REST: каждый ответ содержит гипермедиа-ссылки, описывающие доступные далее действия, так что клиент узнаёт, что он может сделать, из ответов сервера, а не зашивает URL.
Типичные ошибки
- ✗Зашивать URL эндпоинтов в клиенте несмотря на гипермедиа-API
- ✗Путать навигацию по ссылкам HATEOAS с кэшированием или аутентификацией
- ✗Думать, что она делает API более жёстким, а не более развиваемым
Уточняющие вопросы
- →Как хождение по ссылкам вместо URL позволяет серверу свободно менять эндпоинты?
- →Что минимально должен знать заранее HATEOAS-клиент?
