НейроАгент

Коды статуса HTTP для операций PUT и DELETE

Узнайте лучшие коды статуса HTTP для успешных операций PUT и DELETE в REST API. Узнайте, когда использовать 204 No Content, 200 OK или 202 Accepted на основе стандартов RFC и требований к проектированию API.

#api-design #delete-operation #http-status-codes #put-operation #rest-api #rfc-standards #web-development

29.10.2025, 18:25

Вопрос

Какой HTTP-статус-код следует использовать для успешных операций UPDATE (PUT) и DELETE в REST API?

НейроАгент

Для успешных операций UPDATE (PUT) и DELETE в REST API наиболее подходящими кодами состояния HTTP являются 204 No Content (когда не требуется тело ответа) или 200 OK (при возврате информации об обновленном ресурсе). Согласно RFC 7231, операции DELETE также могут возвращать 202 Accepted для асинхронных операций. Выбор между этими кодами зависит от того, возвращает ли ваше API тела ответов и является ли операция синхронной или асинхронной.

Коды состояния для операций PUT

При реализации успешных операций UPDATE с использованием метода HTTP PUT у вас есть несколько вариантов кодов состояния:

204 No Content — это наиболее часто рекомендуемый код состояния для успешных операций PUT, когда:

Операция обновления завершена успешно
Не требуется возвращать тело ответа клиенту
Клиенту не нужно переходить с текущей страницы
Вы хотите минимизировать сетевой трафик

Ответ HTTP 204 No Content по умолчанию кэшируется и не включает тело сообщения, что делает его эффективным для операций обновления.

200 OK следует использовать, когда:

Вы хотите вернуть клиенту представление обновленного ресурса
Клиенту требуется подтверждение обновленного состояния
Ваш дизайн API включает возврат тел ресурсов для успешных обновлений

Как отмечается в обсуждении на Stack Overflow, нет требований RFC, согласно которым PUT никогда не должен возвращать тело, и 200 OK с телом ответа вполне приемлем.

202 Accepted может быть уместен для:

Асинхронных операций обновления
Когда запрос принят, но обработка еще не завершена
Длительных операций обновления

Коды состояния для операций DELETE

Для успешных операций DELETE спецификация HTTP предоставляет четкие указания согласно RFC 7231:

204 No Content — предпочтительный выбор, когда:

Ресурс успешно удален
Не требуется предоставлять дополнительную информацию
Вы хотите указать на успех без возврата тела ответа

В блоге Moesif объясняется: “204 No Content — наиболее подходящий код состояния для этого случая. Лучше уменьшить трафик и просто сообщить клиенту, что удаление завершено, и не возвращать тело ответа (поскольку ресурс уже удален).”

200 OK следует возвращать, когда:

Вы хотите вернуть информацию об удаленном ресурсе
Клиенту требуется подтверждение того, что было удалено
Ваш дизайн API включает сообщения об успехе с полезной нагрузкой

202 Accepted подходит для:

Асинхронных операций удаления
Когда запрос на удаление принят, но еще не обработан
Фоновых операций удаления, которые требуют времени для завершения

Стандарты RFC и лучшие практики

Спецификация RFC 7231 предоставляет авторитетные указания по кодам состояния HTTP:

“Если метод DELETE успешно применен, исходный сервер ДОЛЖЕН отправить код состояния 202 (Accepted), если действие, вероятно, будет успешным, но еще не выполнено, код состояния 204 (No Content), если действие выполнено и дальнейшая информация не требуется, или код состояния 200 (OK)…”

Это устанавливает три основных кода состояния успеха для операций DELETE в зависимости от характера операции.

Для операций PUT, хотя RFC 7231 не указывает обязательные коды состояния, документация HTTP.dev уточняет, что “когда получен код состояния 204 No Content, это ответ HTTP на операцию, такую как POST, PUT или DELETE, где не ожидается тело сообщения.”

Ключевые лучшие практики, соответствующие RFC, включают:

Использование 204 No Content, когда не требуется тело ответа
Обеспечение того, чтобы ответы 204 не включали тело сообщения
Последовательность в использовании кодов состояния в вашем API
Предоставление соответствующих заголовков Allow при поддержке нескольких методов

Распространенные сценарии и рекомендации

Сценарии операций PUT

Сценарий 1: Обновление профиля пользователя

Используйте 204 No Content, если клиенту не требуются обновленные данные профиля
Используйте 200 OK с обновленными данными профиля, если клиенту требуется подтверждение

Сценарий 2: Обновление с ошибками валидации

Используйте 400 Bad Request для ошибок валидации на стороне клиента
Используйте 422 Unprocessable Entity для проблем валидации на стороне сервера

Сценарий 3: Частичные обновления (PATCH)

Рассмотрите возможность использования 200 OK с представлением обновленного ресурса
Используйте 204 No Content для успешных обновлений, когда ответ не требуется

Сценарии операций DELETE

Сценарий 1: Синхронное удаление файла

Используйте 204 No Content для немедленного успешного удаления
Используйте 200 OK, если вы хотите вернуть метаданные об удаленном файле

Сценарий 2: Асинхронная очистка ресурсов

Используйте 202 Accepted, чтобы указать, что запрос поставлен в очередь
Завершите ответом 204 No Content, когда операция завершена

Сценарий 3: Ресурс не найден

Используйте 404 Not Found, если ресурс не существует
Однако, как отмечается в статье Tugberk Ugurlu, “Если ресурс уже удален, и вы получаете HTTP DELETE запрос для этого ресурса, в этом случае возвращайте 200 или 204; не 404”

Источники

Заключение

Для операций PUT: Используйте 204 No Content, когда не требуется тело ответа, или 200 OK при возврате обновленных данных ресурса. 202 Accepted подходит для асинхронных операций.
Для операций DELETE: Следуйте указаниям RFC 7231 — используйте 204 No Content для немедленного успеха, 200 OK при возврате метаданных, или 202 Accepted для асинхронной обработки.
Последовательность — ключ: Выберите шаблон и придерживайтесь его во всем вашем API для предсказуемого поведения.
Учитывайте потребителей вашего API: Подумайте, какую информацию клиентам нужно после успешных операций, чтобы направить ваш выбор кодов состояния.
Обработка ошибок важна: Реализуйте соответствующие коды ошибок (400, 401, 403, 404, 422 и т.д.) для различных сценариев сбоев.

Следуя этим лучшим практикам, соответствующим RFC, ваш REST API будет более предсказуемым, эффективным и легким для использования разработчиками.

Какой код статуса HTTP следует использовать для успешных операций POST в REST API?Как следует обрабатывать операции PATCH в кодах статуса REST API?Какие существуют лучшие практики обработки ошибок в кодах статуса REST API?Когда следует использовать 201 Created вместо 200 OK для успешных POST-запросов?Чем отличаются коды статуса между синхронными и асинхронными операциями API?Какие распространенные ошибки следует избегать при реализации кодов статуса REST API?

Спросить у NeuroAgent