Ответ
Тело запроса (request body) может присутствовать в следующих HTTP-методах:
- POST — для создания нового ресурса.
- PUT — для полной замены ресурса.
- PATCH — для частичного обновления ресурса.
- DELETE — редко, но спецификация допускает тело для передачи дополнительных параметров удаления.
Почему? Методы GET, HEAD, OPTIONS и TRACE семантически предназначены для получения информации о ресурсе, а не для передачи данных на сервер, поэтому тело запроса для них обычно не используется или игнорируется.
Пример POST-запроса с телом в формате JSON:
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
{
"name": "Alice",
"email": "alice@example.com"
}Best Practice: Всегда явно указывайте заголовок Content-Type (например, application/json) при отправке тела запроса.
Ответ 18+ 🔞
Давай разберём эту хуйню про тело запроса, а то народ путается, как последние идиоты.
Смотри, есть такие методы, которые по своей сути — чистые потребители. Им нужно не просто адрес сказать, а ещё и впихнуть туда целую пачку данных. Вот главные обжоры:
- POST — классика. «Создай мне на сервере что-то новое, вот тебе чертежи».
- PUT — перфекционист. «Возьми этот новый объект и полностью замени им старый, чтобы ни пылинки не осталось».
- PATCH — хирург. «Не трогай всё подряд, вот тебе заплатка, обнови только то, что я указал».
- DELETE — да, иногда и он может быть с телом! Редко, но метко. Например, чтобы передать список ID для удаления или причину, почему всё пошло нахуй.
А теперь внимание, вопрос на засыпку: почему в GET, HEAD, OPTIONS и TRACE тело обычно не светят?
Да потому что они, блядь, семантически другие! Их задача — получить информацию о ресурсе (что там, как там, можно ли), а не запихивать в сервер свои данные. Если ты пошлёшь тело в GET, сервер, скорее всего, посмотрит на тебя как на идиота и проигнорирует. Это как прийти в библиотеку и начать читать лекцию библиотекарю — не по адресу, дружок.
Лайфхак, чтобы не выглядеть конченым: Всегда, блядь, всегда явно указывай заголовок Content-Type, когда шлёшь тело. Сервер — не экстрасенс, он должен понимать, в каком формате ты ему эту простыню текста подсовываешь: JSON, XML или просто набор матерных выражений.
Вот, смотри, как культурный человек делает POST:
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
{
"name": "Alice",
"email": "alice@example.com"
}Видишь? Чётко, ясно. Метод POST, адрес /api/users, и в теле — аккуратный JSON, о котором мы предупредили заголовком. Красота, ёпта! Никаких вопросов. А если бы Content-Type не указали, сервер мог бы и охуеть от такого сюрприза.