Ответ
Выбор HTTP-метода зависит от семантики операции (создание, обновление, замена) и идемпотентности.
| Метод | Назначение (Семантика) | Идемпотентность | Безопасность | Тело запроса |
|---|---|---|---|---|
POST |
Создание нового ресурса. Основной метод для отправки данных. | Нет | Нет | Да |
PUT |
Полная замена ресурса по известному URI. Если ресурса нет — создает. | Да | Нет | Да |
PATCH |
Частичное обновление ресурса. | Нет* | Нет | Да |
GET |
Получение данных. Не должен использоваться для отправки, т.к. данные в URL, есть ограничения по длине и кэшированию. | Да | Да | Нет |
Почему POST — основной выбор для отправки?
Он не имеет ограничений GET (данные в теле, нет лимита длины) и четко указывает на намерение создать что-то новое, что не является идемпотентной операцией.
Пример POST-запроса для создания пользователя:
POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJ...
{
"name": "Alice",
"email": "alice@example.com",
"role": "viewer"
}Ожидаемый успешный ответ: HTTP/1.1 201 Created с заголовком Location: /api/v1/users/123 и телом созданного ресурса.
Ответ 18+ 🔞
Давай разберём эту хуйню про HTTP-методы, а то некоторые думают, что GET — это универсальный ключ от всех дверей, а потом удивляются, почему их API нихуя не работает.
Смотри, вся соль в том, что ты хочешь сделать и как это сделать правильно, чтобы сервер не послал тебя нахуй.
| Метод | Зачем он нужен (Суть) | Идемпотентный? | Безопасный? | Можно ли тело? |
|---|---|---|---|---|
POST |
Создать новый ресурс. Твой главный инструмент, чтобы что-то запихнуть на сервер. Ты как бы говоришь: «Эй, прими это и сделай с этим что-нибудь новенькое». | Нет | Нет | Да |
PUT |
Полностью заменить ресурс по известному адресу. Нет ресурса? Создаст. Есть? Перезатрёт нахуй. | Да | Нет | Да |
PATCH |
Обновить ресурс частично. Типа «вот только имя поменяй, остальное не трогай». | **Нет*** | Нет | Да |
GET |
Получить данные. НЕ ДЛЯ ОТПРАВКИ! Данные в URL, длина ограничена, всё может закэшироваться — пиздец, а не метод для создания. | Да | Да | Нет |
Так почему же POST — наш бро?
Потому что у него нет этих ебаных ограничений GET. Данные летят в теле, можно запихнуть овердохуища информации, и его семантика кричит: «Я тут что-то новое творю!». Это операция не идемпотентная — десять раз нажмёшь «отправить», и получишь десять новых записей в базе, если не предусмотрена защита. Волнение ебать!
Вот как выглядит нормальный POST-запрос, когда ты создаёшь пользователя:
POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJ...
{
"name": "Alice",
"email": "alice@example.com",
"role": "viewer"
}И если всё прошло хорошо, сервер должен ответить тебе примерно так:
HTTP/1.1 201 Created (статус «Создано», а не просто «ОК»!), в заголовке Location даст ссылку на нового пользователя (/api/v1/users/123) и в теле вернёт его же, созданного, чтобы ты мог проверить.
Вот и вся магия. Не выёбывайся с GET для отправки данных, и будет тебе счастье.