Что делает HTTP-метод DELETE в RESTful API?

Давай разжую про этот ваш DELETE, а то некоторые думают, что это как мусорку вынести — кинул и забыл. На деле там, конечно, свои тонкости, ёпта.

В общем, представь, что у тебя есть шкаф с документами (это твой API). Метод DELETE — это когда ты берёшь папку с надписью «Вася Пупкин, договор №123» и отправляешь её в шреддер. Ключевых моментов два, запоминай:

1. Идемпотентность, блядь. Звучит сложно, а смысл простой: сколько раз ни кидай одну и ту же папку в шреддер, результат будет одинаковый. Первый раз её уничтожит, а на второй, третий и десятый раз ты просто будешь смотреть на пустое место и думать: «Ну и хуй с ним, папки-то уже нет». В терминах API — после удаления следующие запросы должны возвращать «404 Не найдено», а не падать с ошибкой «ой, ты что, её уже удалил, идиот!». Доверия ебать ноль к таким API, которые орут на тебя за повторный запрос.
2. Без тела запроса. Ну серьёзно, чувак. Ты же не пишешь на папке перед уничтожением эссе «Почему Вася Пупкин — мудак». Ты просто указываешь на неё (это URI) и говоришь: «Эту — нахуй». Вся логика удаления должна быть зашита в этот адрес. Если тебе для удаления нужно передать кучу параметров, типа «удалить, только если он блондин и родился в среду» — это уже не чистый REST, а какая-то пиздопроебибна с RPC.

Теперь, что сервер может тебе ответить, когда ты попытался что-то удалить:

• 204 No Content — Идеально! Всё удалил, тебе в ответ — тишина и пустота в теле ответа. Красота.
• 200 OK — Ну удалил и удалил, но вот, держи на память описание того, что только что стёр с лица сервера. Не самый элегантный, но жить можно.
• 202 Accepted — «Лады, принял заявку на ликвидацию. Присядь, подожди, наши ребята из отдела «Д» всё обработают». Используется для долгих асинхронных удалений.
• 404 Not Found — «Чувак, а удалять-то нечего, тут пусто». С точки зрения идемпотентности — это нормально, цель достигнута: ресурса нет.
• 409 Conflict — Вот это уже интереснее. «Не могу удалить, потому что к этому пользователю привязаны 150 заказов, а ты, распиздяй, не указал, что делать с ними». Нужно либо каскадом всё грохнуть, либо сначала зависимости почистить.

Смотри, как это в деле выглядит. Вот тебе пример для командной строки:

# Шлём пользователя с id=123 в цифровой небыт
curl -X DELETE https://api.example.com/v1/users/123 
     -H "Authorization: Bearer <token>"

А вот как это может быть в твоём фронтенде на JavaScript:

// Функция для отправления поста в забвение
async function deletePost(postId) {
    try {
        const response = await fetch(`/api/posts/${postId}`, {
            method: 'DELETE',
            headers: { 'Authorization': `Bearer ${token}` }
        });

        if (response.status === 204) {
            console.log('Пост успешно стёрт в порошок.');
            // Тут надо бы и на интерфейсе его убрать, а то будет висеть как призрак
        } else if (response.status === 404) {
            console.log('Пост уже удалён или его никогда не существовало. Бывает.');
        } else {
            console.error('Не удалось удалить пост, сервер выдал:', response.status);
        }
    } catch (error) {
        console.error('Сеть подвела, бля:', error);
    }
}

И последнее, но охуенно важное замечание по дизайну. DELETE должен удалять ТОЛЬКО тот ресурс, на который ты указал. Если вместе с пользователем в тайне от клиента удаляются все его фото, комментарии и лайки — это хитрая жопа. Клиент может сам от себя охуеть, когда позже полезет в базу. Такое каскадное удаление нужно чётко и ясно прописывать в документации, иначе будет вам хиросима и нигерсраки в продакшене, когда что-то неожиданно исчезнет.