Как передаются данные в GET запросе

Что проверяют

Умеете ли вы корректно собрать URL с параметрами из кода и понимаете ли, как это влияет на кеш, CORS и состояние интерфейса. Следом часто спрашивают, зачем хранить фильтры каталога в URL и что делать, когда параметров становится слишком много.

Как отвечать

Данные GET-запроса едут в URL: путь (/products/42) и строка запроса после ? с парами key=value через &. Плюс заголовки и cookies. Тела у GET нет: fetch с методом GET и body бросает TypeError.

Собирать URL руками не нужно:

• URL и URLSearchParams: url.searchParams.set("q", query) сам закодирует пробелы, &, # и кириллицу. Для массива вызывайте append несколько раз, а читайте через getAll;
• encodeURIComponent: если всё же собираете строку, кодируйте каждое значение. encodeURI для этого не подходит, он оставляет &, = и ? как есть;
• форма с method="get": браузер сам сериализует поля в строку запроса, пробел превращается в +;
• роутер: фильтры и пагинацию держат в URL через useSearchParams в React Router или Next.js. Состояние переживает перезагрузку, ссылкой можно поделиться, работает кнопка «Назад».

Про кеш: ответы на GET кешируются браузером и CDN по полному URL, поэтому ?a=1&b=2 и ?b=2&a=1 для кеша разные ключи. Стабильный порядок параметров повышает попадание в кеш.

Про CORS: кросс-доменный GET только с разрешёнными по умолчанию заголовками идёт без preflight, а собственный заголовок вроде X-Api-Key добавит запрос OPTIONS.

Где спотыкаются

Склеивают строку без кодирования: "/search?q=" + value. Значение с & или # обрезает запрос или подменяет соседние параметры.

Кладут в URL токены и персональные данные. URL остаётся в истории, логах сервера и аналитике, а при переходах внутри сайта уходит в Referer.

Упираются в длину. Браузеры держат длинные URL, но nginx и многие CDN по умолчанию режут примерно на 8 КБ и отвечают 414. Сложный фильтр переводят в POST на отдельный endpoint поиска или сохраняют на сервере и передают его ID.