Скажем, у меня есть ресурс, который может иметь два разных поведения, когда delete называется
Как смоделировать его с помощью метода REST?
Я подумал о следующем решении:
DELETE /myresource
перемещает ресурс в корзину (поведение по умолчанию)
DELETE /myresource?force-delete=true
принудительно удаляет ресурс.
Соответствует ли REST? Я никогда не видел параметры запроса в URL-адресе при вызове DELETE, это нормально?
Чистая стратегия REST должна предпочесть не меняющиеся ресурсы. По-моему, вы не меняете ресурс, добавляя параметр, поэтому для меня это выглядит как хорошая стратегия.
Если бы вы выполнили одно и то же действие:
DELETE /myresource.force
который будет действовать как другой ресурс, который не был бы оптимальным.
Ваша идея в порядке, но я думаю, что пользовательский заголовок запроса будет немного более подходящим. Параметры запроса лучше подходят, ну, параметры.
Пользовательский заголовок запроса будет выглядеть примерно так:
DELETE /myresource
X-Really-Delete: Yup
Почему бы и нет? Вы уже передаете параметр, чтобы определить, какой ресурс, поэтому отправьте еще один, чтобы установить другой курс действий. ИМО, он отлично RESTful.
Вы также можете реализовать 2. как запрос POST вместо DELETE.
POST /myresource
recycle-bin=true...
Как и во всем, что вы делаете, это обновление ресурса, чтобы указать, что оно находится в корзине.
EDIT: измененный метод от PUT до POST с учетом PUT должен заключить полную замену (или добавление) ресурса, тогда как ясно здесь мы обновляем только часть ресурс.
DELETE должен удалить элемент, без вопросов.
К сожалению, в HTTP нет запроса "MOVE". POST обычно предназначен для создания контента, PUT - больше изменений.
Итак, я предлагаю вам сделать что-то вроде PUT /myresource с некоторой формой метаданных или json-строкой вдоль строк { "recycle":"true" }, чтобы указать, что вы хотите "переработать" ее.