В чем разница между Path (путевым) и Query (строковым) параметром в REST API?

Question

В чем разница между Path (путевым) и Query (строковым) параметром в REST API?

Тип вопроса: API тестирование Вероятность: 24% Категория: AQA / Automation

Ответ

Как тестировщик API, я четко различаю эти два типа параметров, так как они по-разному влияют на структуру запроса, тестовые сценарии и валидацию ответов.

Path Parameters (Параметры пути)

Расположение: Встроены в сам путь URL, обычно обозначаются фигурными скобками {} в шаблоне маршрута.
Назначение: Идентифицируют конкретный ресурс или иерархию ресурсов. Они обязательны для маршрутизации запроса к нужному обработчику.
Семантика: Часть идентификатора ресурса (URI).
Пример для тестирования:
```
GET /api/users/{userId}/orders/{orderId}
GET /api/users/567/orders/8921
```
- Что проверяем:
  1. Корректность извлечения userId=567 и orderId=8921 сервером.
  2. Ответ 404 Not Found при передаче несуществующего ID.
  3. Ответ 400 Bad Request при передаче нечислового ID, если endpoint ожидает число.

Query Parameters (Параметры строки запроса)

Расположение: Добавляются в конец URL после знака ?, пары ключ=значение разделяются &.
Назначение: Осуществляют фильтрацию, сортировку, пагинацию или модификацию запроса к ресурсу(-ам). Они необязательны.
Семантика: Параметры операции над ресурсом.
Пример для тестирования:
```
GET /api/orders?status=shipped&limit=10&sort=-date
```
- Что проверяем:
  1. Корректную фильтрацию списка заказов по status='shipped'.
  2. Ограничение вывода 10 записями (limit=10).
  3. Сортировку по убыванию даты (sort=-date).
  4. Поведение при невалидных значениях (например, status=invalid).
  5. Значения по умолчанию при отсутствии параметров.

Сводная таблица для тест-кейсов

Критерий	Path Parameter	Query Parameter
Обязательность	Обязателен для маршрутизации	Опционален
Влияние на ресурс	Определяет какой ресурс	Определяет как представить ресурс(ы)
Типовые тесты	Валидация формата, граничные значения, негативные сценарии (несуществующий ID)	Комбинаторика параметров, значения по умолчанию, специальные символы (кодирование), пустые значения
Пример в тест-плане	`GET /products/0` (проверка на несуществующий ID)	`GET /products?category=&price=abc` (проверка обработки пустого и нечислового значения)

Понимание этой разницы критично для составления полного набора тестов: позитивных, негативных и проверки граничных условий как для пути, так и для строки запроса.

Ответ 18+ 🔞

Э, слушай, вот сидишь ты такой, тестируешь API, и тут бац — нужно разобраться, где тут path, а где query. А разница-то, бля, принципиальная, как между «пойди туда» и «пойди туда, но вот так». Сейчас разжуем, чтобы ни у кого сомнений не осталось.

Path Parameters (Параметры пути, они же вшитые в адрес)

Где торчат: Прямо в самом URL, как гвозди в доске. Обычно зашиты в фигурные скобки {} в роуте. Без них сервер просто нихуя не поймёт, куда запрос слать.
Зачем нужны: Чтобы ткнуть пальцем в конкретный ресурс. Типа «дай мне пользователя номер 567» или «покажи заказ 8921 у этого самого пользователя». Это не параметры запроса, это часть самого адреса, ёпта.
Как выглядит в деле:
```
GET /api/users/{userId}/orders/{orderId}
GET /api/users/567/orders/8921
```
- На что орать при тестах:
  1. Сервер правильно выковырил userId=567 и orderId=8921? Или он там нихуя не понял?
  2. Если подсунуть левый, несуществующий ID — прилетает ли честный 404 Not Found? Или какая-нибудь хуйня в ответе?
  3. А если впихнуть буквы вместо цифр (если endpoint ждёт число) — получаем ли адекватный 400 Bad Request? Или сервер просто охуеет и упадёт?

Query Parameters (Параметры строки запроса, они же прицеп)

Где болтаются: Тыкаются в конец URL, после знака вопроса ?. Формат классический: ключ=значение, а если их несколько — разделяются амперсандом &. Могут быть, а могут и не быть — от них запрос не сломается.
Зачем нужны: Это уже не «что дай», а «как дай». Фильтрация, сортировка, пагинация — вся эта муть. «Дай заказы, но только отправленные, и только 10 штук, и отсортированные по дате наоборот».
Как выглядит в деле:
```
GET /api/orders?status=shipped&limit=10&sort=-date
```
- На что орать при тестах:
  1. Фильтр status='shipped' реально отфильтровал заказы? Или он проигнорирован и пришли все подряд?
  2. limit=10 честно обрезал вывод до десяти записей? Или там овердохуища данных пришло?
  3. Сортировка sort=-date работает? Самые свежие заказы в начале?
  4. А что будет, если передать какую-нибудь дичь, типа status=invalid? Упадёт, вернёт ошибку или проигнорирует?
  5. И самое главное — значения по умолчанию. Если не передать ни одного параметра — что вернётся? Полный список? Или какая-то умолчательная пагинация?

Короче, сводная таблица, чтобы не ебать мозг

Критерий	Path Parameter	Query Parameter
Обязательность	Без них — нихуя не работает. Обязательны.	По желанию. Можешь передать, а можешь и нет.
Влияние на ответ	Определяет, какой именно ресурс тащить.	Определяет, в каком виде этот ресурс (или список) отдать.
На что тестить	Валидация формата (число ли там), граничные значения, негатив (несущ. ID).	Комбинации параметров, дефолтные значения, спецсимволы (кодирование!), пустые значения.
Пример теста	`GET /products/0` — проверяем, что ноль — невалидный ID.	`GET /products?category=&price=abc` — проверяем, как серв обрабатывает пустоту и буквы в числовом поле.

Вот и вся магия. Понимание этой разницы — это, бля, основа основ. Без этого ты будешь как мартышлюшка с гранатой: кидаешь запросы, а потом охуеваешь от результатов. Тестируй и путь, и строку запроса — и позитив, и негатив, и все граничные условия. Тогда будет тебе счастье, а не пиздец.