Есть ли что-нибудь не-RESTful в предоставлении параметров для запроса HTTP DELETE?
Мой сценарий состоит в том, что я моделирую "Вы уверены, что хотите удалить это?" сценарий. В некоторых случаях состояние ресурса предполагает, что запрошенное удаление может быть недействительным. Вы можете себе представить некоторые сценарии, где требуется подтверждение удаления
Решение, которое мы приняли, заключается в передаче параметра в запрос на удаление, чтобы указать, что можно продолжить удаление («? Force_delete = true»)
, например
DELETE http://server/resource/id?force_delete=true
Я считаю, что это все еще успокаивает, так как:
(a) Семантика DELETE не изменяется - пользователь все еще может отправить обычный запрос DELETE, но этот может завершиться ошибкой с 409, и тело ответа объяснит почему. Я говорю, что может потерпеть неудачу, потому что (по причинам, не стоящим объяснения) в некоторых случаях нет никаких причин, чтобы побуждать пользователя.
(б) В диссертации Роя нет ничего, что могло бы предположить, что это противоречит духу REST - почему бы это сделать, поскольку HTTP является лишь одной реализацией REST, поэтому почему передача параметров HTTP имеет значение
Может ли кто-нибудь указать мне на однозначное утверждение, объясняющее причину, по которой это не RESTful?
По связанному вопросу, если пользователь не указывает force_delete, то я возвращаю 409 Conflict
- это самый подходящий код ответа?
Последующие действия
После некоторых дальнейших исследований, я думаю, что добавление параметров в DELETE может нарушить несколько принципов.
Во-первых, реализация, возможно, нарушает «Единый интерфейс» (см. Раздел 5.1.5 Диссертация Роя
Добавляя force_delete, мы добавляем дополнительное ограничение к уже определенному методу DELETE. Это ограничение имеет значение только для нас.
Вы также можете утверждать, что это нарушает «Клиент-сервер 5.1.2», так как диалог подтверждения действительно является проблемой пользовательского интерфейса, и снова не все клиенты захотят подтвердить удаление.
Предложения кому-нибудь?