Как разделяются query параметры от метода в URL
Что проверяют
Знаете ли вы анатомию URL настолько, чтобы собрать запрос руками и прочитать его в DevTools. Под «методом» здесь обычно понимают эндпоинт, путь вроде /api/users, и сильный ответ отдельно оговаривает, что HTTP-метод (GET, POST) в URL не входит вовсе. Следом просят придумать проверки для параметров.
Как отвечать
Разберите адрес https://shop.test/api/orders?status=paid&limit=20#top по частям:
- путь
/api/orders: ресурс или эндпоинт, заканчивается на первом?; ?: отделяет путь от строки запроса, разделителем служит именно первый знак вопроса;&: разделяет пары, а внутри пары ключ и значение разделены=;#: начинает фрагмент, он остаётся в браузере и на сервер не уходит.
HTTP-метод передаётся в стартовой строке запроса: GET /api/orders?status=paid HTTP/1.1. Поэтому один и тот же URL может обслуживать и GET, и DELETE.
Спецсимволы в значениях кодируются процентами: пробел как %20 (в формах application/x-www-form-urlencoded как +), кириллица как байты UTF-8, & внутри значения как %26. Что интересно проверить:
- повтор ключа
?tag=a&tag=b: одни фреймворки берут первое значение, другие последнее, третьи собирают массив; - пустое значение и отсутствие ключа:
?limit=и запрос безlimitэто разные случаи; - границы и типы:
limit=0,-1,abc, очень большое число; - длина URL: у серверов есть лимит, при превышении обычно приходит
414 URI Too Long; - чувствительные данные: токены в query оседают в логах сервера и истории браузера, это уже баг безопасности.
Смотреть удобно во вкладке Params в Postman и в DevTools: Network, запрос, вкладка Payload.
Где спотыкаются
Говорят, что метод указывается в URL. Это смешивает эндпоинт и HTTP-метод, и интервьюер почти наверняка за это зацепится.
Считают # ещё одним параметром. Всё после решётки сервер не видит, и проверять это на бэкенде бессмысленно.
Вставляют URL с & в curl без кавычек. Шелл воспринимает & как запуск в фоне, запрос уходит обрезанным, и найденный «баг» оказывается ошибкой самого теста.