Чем POST отличается от DELETE

POST можно читать как: "сервер, возьми эти данные и выполни действие". Часто результатом будет новый пользователь, заказ или комментарий. Но POST используют и там, где нет чистого CRUD: отправить письмо, запустить импорт, пересчитать отчет.

DELETE звучит конкретнее: "удали вот этот ресурс". Поэтому хороший адрес обычно сам показывает цель удаления: DELETE /users/123, DELETE /todos/42.

У POST и DELETE разный контракт между фронтендом и бэкендом. Отличается не только метод, но и место для данных, ожидаемый статус, обработка ошибок и следующий шаг в интерфейсе.

POST /users
Content-Type: application/json

{ "name": "John", "email": "john@example.com" }

Нормальный ответ на создание:

201 Created
Location: /users/123

Удаление того же пользователя обычно выглядит так:

DELETE /users/123

ID не нужно прятать в body. URL уже говорит, какой ресурс удаляется.

Идемпотентность означает простую вещь: один и тот же запрос можно повторить, и итоговое состояние будет таким же, как после одного выполнения.

С обычным POST это не гарантируется:

POST /orders
Content-Type: application/json

{ "productId": 10, "count": 1 }

Если пользователь дважды нажмет кнопку или retry-механизм повторит запрос, сервер может создать два заказа. Для платежей и заказов это больно, поэтому в таких API часто вводят Idempotency-Key или другую защиту от дублей.

У DELETE другая семантика:

DELETE /orders/42

После первого запроса заказа 42 нет. После второго его тоже нет. Сервер может ответить уже не 204, а 404, но он не должен из-за повтора удалить что-то еще.

Пример POST с явной проверкой статуса:

type UserPayload = {
  name: string;
  email: string;
};

const createUser = async (payload: UserPayload) => {
  const response = await fetch("/api/users", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(payload),
  });

  if (response.status !== 201) {
    throw new Error("Пользователя не удалось создать");
  }

  return response.json();
};

Пример DELETE, где успешный ответ может быть пустым:

const deleteUser = async (userId: string) => {
  const response = await fetch(`/api/users/${userId}`, {
    method: "DELETE",
  });

  if (response.status === 204) {
    return;
  }

  if (response.status === 404) {
    throw new Error("Пользователь уже удален или не найден");
  }

  if (!response.ok) {
    throw new Error("Пользователя не удалось удалить");
  }
};

Здесь легко ошибиться и вызвать response.json() после 204 No Content. Тела у такого ответа нет, значит парсить нечего.

После успешного DELETE экран должен перестать показывать удаленный объект. Обычно хватает одного из трех действий: убрать элемент из локального состояния, инвалидировать кэш запроса или заново получить список.

С optimistic UI лучше не геройствовать. Можно сразу убрать карточку, чтобы интерфейс казался быстрым. Но если сервер вернет 403, 404, 409 или случится сетевая ошибка, карточку надо вернуть и показать нормальное сообщение.

В реальных проектах встречается POST /users/123/delete. Иногда это наследие старого API, ограничение шлюза, HTML-форма без поддержки DELETE или просто договоренность команды. Это не катастрофа, но если вы проектируете REST API с нуля, DELETE /users/123 читается лучше.

DELETE описывает намерение клиента, а не физическую операцию в базе. Бэкенд может удалить строку, поставить deletedAt, сменить статус на archived или скрыть объект из выдачи. Для клиента это все равно удаление, и внешний контракт может оставаться DELETE /users/123.

POST и DELETE меняют состояние сервера. Если авторизация держится на cookie, для таких запросов обычно нужна CSRF-защита. И еще раз: DELETE не становится safe только потому, что он идемпотентен. Safe означает "не меняет состояние", а удаление состояние меняет.