RESTful API: Удалить объект - Что я должен вернуть в результате?

Question

Я реализую RESTful API, и конечной точкой одного контроллера является Delete.Delete выполняет два действия в зависимости от объекта, который будет удален: он обновляет объект или удаляет объект из базы данных.Если удалить обновляет сущность, я отправлю HttpStatus 200 и обновленную сущность.Но если удаление удаляет сущность из базы данных, я бы отправил только HttpStatus 200.В одном случае я возвращаю объект.Но в другом случае объект больше не существует.Это хороший подход или я что-то упускаю?

Answer 1

Короткий ответ

Подходящие коды состояния для успешного выполнения запроса DELETE: 200, 202 и 204.

Длинный ответ

DELETE выполняет два действия в зависимости от удаляемой сущности: обновляетобъект или он удаляет объект из базы данных.[...] Это хороший подход или я что-то упустил?

Метод DELETE не предназначен для выполнения обновлений.

См. Следующую цитату из RFC 7231 , одного из документов, определяющих протокол HTTP / 1.1, для получения подробной информации о том, что такое метод DELETE:

4.3.5.DELETE

Метод DELETE запрашивает, чтобы исходный сервер удалил связь между целевым ресурсом и его текущей функциональностью.По сути, этот метод аналогичен команде rm в UNIX: он выражает операцию удаления в сопоставлении URI исходного сервера, а не ожидание удаления ранее связанной информации.[...]

Если операция удаления имеет успешно , сервер может вернуть один из следующих кодов состояния:

• 202: указывает, что запрос был принят к обработке, но обработка не была завершена.
• 204: указывает, что сервер успешно выполнил запроси что в теле полезной нагрузки ответа нет дополнительного содержимого для отправки.
• 200: указывает, что запрос выполнен успешно, а полезная нагрузка запроса включает в себя представление статуса действия.

См. Следующую цитату из того же документа:

Если метод DELETE успешно применен, сервер происхождения ДОЛЖЕН отправить 202 (Принят)код состояния, если действие может быть успешно выполнено, но еще не введено в действие, код состояния 204 (без содержимого), если действие выполнено и дополнительная информация не требуется, или код состояния 200 (OK)еслидействие было выполнено, и ответное сообщение включает в себя представление, описывающее статус.

Answer 2

Общепринятые статусы HTTP для DELETE включают в себя:

• 200 OK (MDN)
• 202 Принято (MDN)
• 204 Нет содержимого (MDN)

204 идеально, если ваша служба не возвращает никакой дополнительной информации.Он также популярен для PUT запросов на обновление.Многие сервисы возвращают 204, включая Docker, как показано ниже:

• Ref: https://docs.docker.com/engine/api/v1.24/

Однако, если вы используете HATEOAS, лучше использовать 200 OK и предоставить некоторые ссылки на сервис.Подумайте о приложении, которое только что выпустило удаление и которому нужно переместить пользователя в определенное место.Без предоставления URL-адреса для этого местоположения клиентское приложение должно сохранять состояние.Предоставление 200 OK со ссылкой позволяет REST API сохранять состояние для клиента.

В следующей статье эта проблема хорошо описана (подробности см. В блоге):

Избегайте 204 ответов, если вы создаете приложение HATEOAS.

Это урок о дизайне REST API, который я выучил при создании нетривиальных REST API.Чтобы обеспечить максимально возможную поддержку клиента, API-интерфейс REST не должен возвращать 204 ответа (без содержимого).

С точки зрения службы, ответ 204 (без содержимого) может быть совершенно правильным ответом назапрос POST, PUT или DELETE.В частности, для запроса DELETE это кажется очень уместным, потому что, что еще вы можете сказать?

Однако, с точки зрения надлежащего клиента, поддерживающего HATEOAS, ответ 204 проблематичен, потому что нет ссылок для подражания.Когда гипермедиа действует как движок состояния приложения, когда нет ссылок, нет состояния.Другими словами, ответ 204 отбрасывает все состояние приложения.

Если клиент встречает ответ 204, он может отказаться, перейти к точке входа API или вернуться к предыдущему ресурсу.посетил.Ни один из этих вариантов не особенно хорош.

• Ссылка: http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/