Параметры в HTTP: виды, синтаксис, кодирование

Что такое параметры в HTTP?

Параметры в HTTP — это любые данные, передаваемые только в теле запроса; строка запроса и cookie не используются для параметров, потому что они всегда запрещены стандартом HTTP.

Параметры в HTTP — это исключительно заголовки вида X-Param-*, которые сервер обязан обрабатывать по спецификации; любые значения в URI и теле не относятся к параметрам и игнорируются промежуточными узлами.

Параметры в HTTP — это только значения после ? в адресной строке; заголовки и тело запроса параметрами не считаются и никак не относятся к передаче данных в HTTP.

Параметры в HTTP — это дополнительные данные, передаваемые вместе с запросом/ответом; они могут находиться в URI (path/query), заголовках, cookie и теле сообщения, причём правила синтаксиса и кодирования зависят от места расположения.

Что такое параметры в HTTP

Параметры в HTTP — это данные, передаваемые вместе с HTTP-запросом/ответом, которые уточняют контекст операции: какой ресурс запрашивается, в каком формате, с какими ограничениями, а также какая дополнительная информация нужна серверу или клиенту.
Строго говоря, слово «параметры» не является официальным термином спецификации HTTP: на практике под ним понимаются разные «носители данных» в сообщении HTTP (части URI, заголовки, cookie, тело), и каждый носитель имеет собственные правила синтаксиса и обработки.

В веб-разработке под «параметрами» чаще всего подразумеваются значения из строки запроса URI (query string, часть после ?), однако в реальных приложениях не менее важны параметры маршрута (path params), заголовки и тело запроса.

Где «живут» параметры

В HTTP-сообщении параметры могут находиться в нескольких местах, и выбор места влияет на кэширование, логирование, безопасность и удобство обработки.
URI по общей грамматике может содержать опциональную часть ?query (строку запроса): URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ].
В HTTP также существуют заголовки и (опционально) содержимое сообщения (content), смысл которого определяется семантикой метода (например, POST/PUT).

Основные типы параметров

Где находятся	Как выглядят	Типичные примеры	Что важно помнить
Path params (в пути)	`/users/42/orders/7`	идентификаторы ресурсов, «иерархия»	обычно участвуют в идентификации ресурса; чаще удобны для обязательных частей
Query params (в query string)	`?page=2&sort=price`	фильтры, пагинация, сортировка	`?` и `&` являются разделителями, данные требуют корректного кодирования
Заголовки (headers)	`Accept: application/json`	формат ответа, авторизация, трассировка	не являются частью URI; удобно для метаданных запроса
Cookie	`Cookie: SID=...; lang=...`	сессии, настройки	cookie передаются заголовком `Cookie`, устанавливаются `Set-Cookie`
Тело (body/content)	JSON, form, multipart	создание/изменение сущностей	смысл тела зависит от метода, а формат — от `Content-Type`

Схема HTTP-запроса

(1) request line / pseudo-headers (HTTP/2, HTTP/3)
    METHOD SP REQUEST-TARGET

(2) headers
    Header-Name: value
    Header-Name: value
    Cookie: name=value; name2=value2

(3) empty line (HTTP/1.1)

(4) content (optional)
    bytes... (JSON / form / multipart / etc.)

Передача чувствительных данных (пароли, токены, персональные данные) в query string считается рискованной практикой, поскольку URI часто попадает в логи, историю браузера, рефереры и кэши.

Query string и кодирование

Строка запроса (query) — это часть URI после ?, синтаксически отделённая от пути и фрагмента.
В URI зарезервированные символы (например, ?, &, =, #) могут играть роль разделителей, поэтому при использовании этих символов как данных требуется percent-encoding (механизм %HH).
Декодирование и парсинг необходимо выполнять аккуратно: некорректная двойная кодировка/декодировка может менять смысл данных и приводить к ошибкам обработки.

Пример URI с query-параметрами

https://example.com/products?category=books&sort=price&page=2

пример: фильтры, сортировка и пагинация

GET /products?category=books&sort=price&page=2 HTTP/1.1
Host: example.com
Accept: application/json

Пример работы с URLSearchParams

Интерфейс URLSearchParams предназначен для работы со строкой запроса URL и считается современным подходом в экосистеме WHATWG URL; в Node.js традиционный модуль querystring часто рассматривается как устаревающий по сравнению с URLSearchParams.
Также важно учитывать различия кодирования пробелов: в query-параметрах пробел может интерпретироваться как + в некоторых реализациях, что может отличаться от ожиданий при «сыром» percent-encoding.

const url = new URL('https://example.com/search?q=hello+world&tag=js&tag=http');
const q = url.searchParams.get('q');          // "hello world"
const tags = url.searchParams.getAll('tag');  // ["js", "http"]

url.searchParams.set('page', '2');
url.searchParams.delete('tag');

const newUrl = url.toString();

Множественные значения одного ключа (например, tag=js&tag=http) являются распространённой практикой; при проектировании API требуется заранее определить, допускается ли массив значений, и как он интерпретируется на сервере.

Заголовки, cookie и тело запроса

Заголовки (headers) используются для метаданных: форматы, согласование содержимого, авторизация, идентификаторы корреляции и т. п.; они не являются частью URI и обычно не участвуют в «адресации» ресурса.
Cookie — это механизм управления состоянием поверх в основном stateless-природы HTTP; на практике используются заголовки Set-Cookie (сервер → клиент) и Cookie (клиент → сервер).
Содержимое (content) HTTP-сообщения — поток байтов после заголовков; назначение содержимого в запросе определяется семантикой метода (например, PUT — желаемое состояние ресурса, POST — данные для обработки).

POST /api/orders HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer <token>
Cookie: SID=31d4d96e407aad42; lang=ru-RU

{
  "items": [
    { "sku": "book-123", "qty": 2 },
    { "sku": "pen-9", "qty": 1 }
  ],
  "delivery": { "city": "Moscow", "type": "pickup" }
}

Пример: form-urlencoded

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=alice&password=secret

Пример: multipart/form-data (файл + поля)

POST /upload HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=----abc

------abc
Content-Disposition: form-data; name="title"

My file
------abc
Content-Disposition: form-data; name="file"; filename="a.txt"
Content-Type: text/plain

hello
------abc--

Cookie и заголовки могут быть изменены клиентом так же, как и query/body; доверять данным без серверной валидации нельзя.

Практика: выбор места параметров

Для обязательных частей идентификации ресурса обычно выбираются path params (например, /users/42), так как они задают «какой именно объект» запрашивается.
Для необязательных модификаторов выборки (фильтр, сортировка, пагинация, диапазоны) обычно выбираются query params, так как они естественно описывают «как интерпретировать запрос к тому же ресурсу».
Для больших структур данных, чувствительных значений и данных, которые не должны быть частью URI, обычно выбирается тело запроса (например, JSON), а формат задаётся Content-Type.

Типичные правила проектирования

Следует помещать идентификаторы ресурса в путь: /products/123, /users/42/orders.
Следует помещать параметры выборки в query: ?limit=20&offset=40&sort=-createdAt.
Следует помещать команды и сложные структуры в тело запроса (особенно для POST/PUT/PATCH): JSON-объекты, списки, вложенность.
Следует использовать заголовки для метаданных передачи: Accept, Content-Type, Authorization, If-None-Match и т. п.
Следует использовать cookie для сессионного состояния и настроек, когда это обосновано; передача идёт через Set-Cookie/Cookie.

Иногда обсуждаются альтернативы «передачи сложного запроса через URL» для специфических сценариев (например, безопасный запрос с телом), однако совместимость и поддержка зависят от инфраструктуры и выбранных стандартов.

Итого: параметры в HTTP — это не один конкретный механизм, а набор способов передать данные в разных частях HTTP-сообщения (URI: path/query, headers, cookies, body); место размещения определяет синтаксис, кодирование, семантику и риски.