Виджет «Request builder» — конструктор запросов в уроке

Когда задание урока просит собрать HTTP-запрос, под текстом появляется встроенный конструктор. Он похож на упрощённый Postman и ничего не требует устанавливать.

Что есть

• Задача — что нужно отправить.
• Метод — GET, POST, PUT, PATCH, DELETE.
• URL — куда отправляется запрос. Обычно это API Sandbox (/api/practice/...).
• Заголовки — список «имя: значение», строки можно добавлять и удалять.
• Тело — JSON для POST, PUT и PATCH. Для GET и DELETE тело не отправляется.
• Кнопка «Отправить» — отправляет запрос по-настоящему и показывает ответ: статус, заголовки и тело.
• Кнопка «Проверить» — отправляет собранный запрос на проверку.

Как проверяется

Проверяется сам запрос, а не ответ сервера: метод, адрес, обязательные заголовки и содержимое тела. Например: «POST на /api/practice/users с Content-Type: application/json и телом, где есть name и email с @». Если что-то не совпало, под виджетом появится сообщение: какого заголовка не хватает или какой метод ожидался.

Типичные ошибки

• Нет Content-Type: application/json у POST с JSON-телом — сервер может не разобрать тело, а проверка укажет на недостающий заголовок.
• Неверный JSON — лишняя запятая, одинарные кавычки вместо двойных. Если сомневаетесь, проверьте тело через JSON.parse(...) в консоли DevTools.
• Не тот метод — PUT вместо POST или наоборот.
• Тело у GET — оно не отправится; данные для GET передают в адресе, параметрами после ?.

Если ответ не принимается

1. Прочитайте сообщение проверки — там сказано, что не совпало.
2. Нажмите «Отправить» и посмотрите на ответ: статус 400 или 422 обычно значит, что тело или заголовки собраны неверно.
3. Сверьте метод и адрес с задачей буква в букву.
4. Если 401 — запросу нужна авторизация: получите токен и добавьте заголовок Authorization: Bearer ….

Что дальше

• Виджет «Форма»
• Практика API Sandbox — все сценарии песочницы
• Виджет «SQL-песочница»