ОТДЫХ - обратимое УДАЛЕНИЕ

Question

У меня есть вопрос о HTTP DELETE и REST.У меня есть ресурс x .В зависимости от состояния x удаление x делает либо:

1. Удаление x навсегда.
2. Пометить x как удаленное.Это означает, что x может быть позже восстановлен.

Я предполагаю, что HTTP DELETE должен удалить ресурс в соответствии со спецификацией HTTP / REST, а не маркироватьнапример, как удаленный: GET для x должен возвращать 404 после обработки HTTP DELETE.Это означает, что HTTP DELETE не может использоваться для второй ситуации. Как бы вы смоделировали это поведение удаления (как 1, так и 2) RESTful-способом?

Затем, поскольку некоторые ресурсы могут быть возвращены, это также должно быть сделано возможным через REST API. Как бы вы смоделировали поведение при обращении RESTful?

Предположим, x находится на http://company/api/x/ для простоты.

Answer 1

Вы можете использовать подход с мусорным баком.

DELETE http://company/api/x/

вызывает перемещение x в мусорную корзину.В этот момент к нему можно получить доступ,

GET http://company/api/trashcan/x/

, и если вы хотите восстановить его, возьмите полученное представление и выполните

PUT http://company/api/x/

---

ОБНОВЛЕНИЕ:

Использование гипермедиа делает для клиента немного более очевидным, что он должен делать.

GET http://company/api/trashcan/x
=>
200 OK

<x-resource>
  <description>This is the object I deleted</description>
  <link rel="restoreto" href="http://company/api/x/" />
</x-resource>

Подумав об этом еще немного, PUT - действительно правильный метод.Это небезопасно, идемпотентно, и вы также знаете URI, где восстановить файл.Если соответствует семантике PUT идеально.Альтернативой rel = "restoreto" может быть rel = "originallocation".

Answer 2

У вас есть ресурс, который может существовать в любом из нескольких состояний (активный, отмечен_для_отделения, удален) с действиями, которые перемещают ресурс из одного состояния в другое. Это классическое определение конечного автомата . Для данного перехода вы задаетесь вопросом: «Какой HTTP-глагол представляет этот конкретный переход? Должен ли я злоупотреблять одним? Является ли POST универсальным? Могу ли я придумать свой собственный?» Существует лучший способ. Выставьте состояние напрямую и используйте GET и PUT для его изменения. Пусть сервер выяснит, как перейти из прежнего состояния в новое. Например, у вас может быть ресурс:

GET /foo -> {"a": 1, "b": 2, "status": "active"}

Вы хотите изменить это так:

GET /foo -> {"a": 1, "b": 2, "status": "marked"}

Вы можете задаться вопросом, подходит ли DELETE для этого или какой-то другой метод, или вы можете просто ПОСТАВИТЬ это новое состояние, и все будет сделано:

GET /foo -> {"a": 1, "b": 2, "status": "active"}
PUT /foo <- {"a": 1, "b": 2, "status": "marked"}
GET /foo -> {"a": 1, "b": 2, "status": "marked"}

Answer 3

RESTful означает, что вы можете использовать POST для выполнения удаления, если хотите, поскольку: В отличие от веб-служб на основе SOAP, не существует «официального» стандарта для веб-служб RESTful.

В этом случае я бы изменил вашу метку для удаления на POST (это на самом деле обновление, а не удаление).