Ответ
Основные методы HTTP, которые я регулярно использую при разработке API и веб-приложений:
- GET: Запрос для получения данных с сервера. Идемпотентный и безопасный (не должен изменять состояние сервера). Используется для загрузки страниц, получения ресурсов из REST API.
- POST: Отправка данных на сервер для создания нового ресурса или выполнения действия. Не идемпотентный. Типичное применение — отправка формы, создание пользователя.
- PUT: Полное обновление существующего ресурса по указанному URI. Идемпотентный.
- PATCH: Частичное обновление ресурса. Также идемпотентный, но обновляет только переданные поля.
- DELETE: Удаление ресурса. Идемпотентный.
- HEAD: Аналогичен GET, но сервер возвращает только заголовки ответа (без тела). Полезен для проверки наличия ресурса или его метаданных.
- OPTIONS: Описание поддерживаемых методов для целевого ресурса (CORS).
Практический пример: В RESTful API для сущности Article я бы использовал:
GET /api/articles # Список статей
POST /api/articles # Создать статью
GET /api/articles/{id} # Получить статью
PUT /api/articles/{id} # Заменить статью целиком
PATCH /api/articles/{id} # Обновить часть статьи
DELETE /api/articles/{id} # Удалить статьюВажно: При проектировании API нужно строго следовать семантике методов, особенно учитывать идемпотентность (GET, PUT, DELETE) для надежности сетевых взаимодействий.
Ответ 18+ 🔞
Давай разберем эту всю ебучую кухню HTTP-методов, чтобы не ходить потом, как манда с ушами, и не путать POST с PUT.
Вот эти ребята, без которых нихуя не работает:
- GET: Это когда ты просто пришёл и взял. Как в холодильник за пивом заглянуть. Ничего не меняется, всё на месте. Используешь, чтобы страницу открыть или данные из API вытащить. Идемпотентный, безопасный — повторяй хоть сто раз, хуй с горы не сдвинется.
- POST: А вот это уже действие, чувак. Ты что-то создаёшь. Отправил форму — бац, на сервере новый пользователь. Нажал кнопку «купить» — заказ создался. Не идемпотентный, потому что если ты его два раза дернёшь, может две одинаковых хуйни создать. Волнение ебать.
- PUT: Полная замена. Представь, у тебя есть профиль. Ты взял и перезаписал его ВЕСЬ новыми данными. Старых полей не осталось. Тоже идемпотентный — сколько раз ни отправляй один и тот же запрос, результат будет как после первого раза.
- PATCH: А это хитрая операция. Ты не весь ресурс меняешь, а только кусочек. Скажем, в том же профиле только аватарку обновил. Тоже, в идеале, идемпотентный должен быть.
- DELETE: Ну тут всё ясно, ёпта. Удалил — и нету. Идемпотентный: удалил один раз — ресурса нет. Удалил второй раз — его всё равно нет, а не ошибка.
- HEAD: Как GET, но тебе в ответ приходит только голова (заголовки), а тело — да похуй. Удобно проверить, жива ли страница или какой у файла размер, не качая его целиком.
- OPTIONS: Спрашиваешь у сервера: «Мужик, а что тут вообще можно делать?». Он тебе список методов отдаёт. Особенно актуально, когда эти гомосеки налетели с CORS-политиками.
Пример из жизни, чтобы вообще ни хуя себе не осталось: Допустим, делаем API для статей. Вот как это выглядит:
GET /api/articles # Вытащить список всех статей
POST /api/articles # Создать новую статью (тут уже данные в теле шлёшь)
GET /api/articles/{id} # Получить одну конкретную статью по ID
PUT /api/articles/{id} # Перезаписать статью целиком
PATCH /api/articles/{id} # Обновить только заголовок, например
DELETE /api/articles/{id} # Отправить статью в пиздуА теперь главное, блядь: Не выёбывайся и следуй смыслу! Если метод идемпотентный (GET, PUT, DELETE), то сервер должен быть готов, что запрос прилетит несколько раз, и ничего не сломается. А то сделаешь в DELETE побочный эффект на каждый вызов — и накроется медным тазом вся твоя логика. Доверия ебать ноль к таким API.
