RESTful стратегия удаления

Допустим, у меня есть ресурс, который может иметь два разных поведения при вызове удаления.

  1. Ресурс удален.
  2. Ресурс перемещается в корзину.

Как смоделировать его в соответствии с REST?

Я подумал о следующем решении:

DELETE /myresource

перемещает ресурс в корзину (поведение по умолчанию)

DELETE /myresource?force-delete=true

принудительно удаляет ресурс.

Совместимо ли это с REST? Я никогда не видел параметры запроса в URL-адресе при вызове DELETE, это нормально?


rest
person LiorH    schedule 04.02.2009    source источник

Ответы (5)


arrow_upward
4
arrow_downward

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

Если бы вы выполнили одно и то же действие следующим образом:

DELETE /myresource.force

это будет действовать как еще один ресурс, что не будет оптимальным.

person ern    schedule 04.02.2009
comment
Это нарушает «правила» REST, поскольку вы обращаетесь к другому ресурсу. В то же время /myresource.json и /myresource.xml предоставляют разные форматы одних и тех же данных (используйте заголовки accept, люди!), но это не исчезнет в ближайшее время. - person Jeffrey Hulten; 17.08.2011
comment
Это не «ОТДЫХ», вы выполняете действия в стиле RPC. - person thecoshman; 27.06.2013

arrow_upward
11
arrow_downward

Ваша идея хороша, но я думаю, что собственный заголовок запроса был бы более подходящим. Параметры запроса лучше подходят, ну, параметры.

Пользовательский заголовок запроса будет выглядеть примерно так:

DELETE /myresource
X-Really-Delete: Yup
person Avi Flax    schedule 05.02.2009

arrow_upward
2
arrow_downward

Почему бы нет? Вы уже передаете параметр, чтобы определить, какой ресурс, поэтому отправьте еще один, чтобы установить другой курс действий. ИМО, это совершенно RESTful.

person Swanand    schedule 04.02.2009

arrow_upward
2
arrow_downward

Вы также можете реализовать 2. как запрос POST вместо DELETE.

POST /myresource

recycle-bin=true...

Как и все, что вы делаете, это обновляете ресурс, чтобы указать, что он находится в корзине.

EDIT: метод изменен с PUT на POST, учитывая, что PUT должен заключать в себе полную замену (или добавление) ресурса, тогда как здесь мы явно обновляем только часть ресурса.

person rojoca    schedule 05.02.2009
comment
Я бы возражал против вашего перехода с PUT на POST. POST для создания контента, PUT для модификации; все, что на самом деле делает OP, - это помечать ресурс определенным значением, то есть обновлять его. - person thecoshman; 11.07.2013
comment
@thecoshman PUT создает или заменяет, что требует, чтобы весь объект был заключен в запрос. Модификации могут быть сделаны с помощью метода PATCH, но он имеет ограниченную поддержку. - person rojoca; 06.08.2013
comment
эээ... как-то. PUT можно использовать для создания контента, как и POST. Разница в том, что с PUT вы создаете определенный URI, а с POST вы просите сервер определить, какой URI хранить. PUT также можно использовать для полной замены ресурса. Вы правы, говоря, что на самом деле PATCH — это правильный способ сделать небольшое обновление, подобное этому. При отсутствии надлежащей поддержки «правильным» решением будет ПОЛУЧИТЬ полный ресурс, обновить его и ПОЛУЧИТЬ полный ресурс обновления обратно на сервер с тем же URI. - person thecoshman; 06.08.2013

arrow_upward
2
arrow_downward

DELETE должен удалить элемент, без вопросов.

К сожалению, в HTTP нет запроса MOVE. POST обычно предназначен для создания контента, PUT — больше модификаций.

Поэтому я бы посоветовал вам сделать что-то вроде PUT /myresource с некоторой формой метаданных или строкой json по строкам { "recycle":"true" }, чтобы указать, что вы хотите «переработать» ее.

person thecoshman    schedule 27.06.2013