Восстановление удаленного RESTful

Это довольно распространенное требование для поддержки восстановления после удаления или отложенного / пакетного удаления для служб данных. Мне интересно, как это реализовать в стиле RESTful. Я разрываюсь между несколькими вариантами (ни один из которых мне не кажется особенно привлекательным). Я считаю, что общим для этих различных вариантов является необходимость в API, который возвращает все ресурсы, помеченные как удаленные для определенного типа ресурса.

Вот некоторые варианты, о которых я подумал, и некоторые из их плюсов и минусов:

Параметры пометки ресурса как удаленного:

• Используйте HTTP DELETE, чтобы пометить ресурс как удаленный.
• Используйте HTTP PUT / POST для обновления флага удаления. Это кажется неправильным, поскольку он отображает то, что по сути является удалением из метода HTTP DELETE, в другие методы HTTP.

Параметры при получении ресурса, помеченного для удаления:

• Вернуть HTTP-статус 404 для ресурса, помеченного как удаленный. Чисто и прозрачно, но как отличить ресурс, который действительно удален, от ресурса, помеченного как удаленный.
• Вернуть HTTP-статус 410. Предоставляет способ определить разницу, но 410 технически говорит, что «ожидается, что он будет считаться постоянным. Клиенты с возможностями редактирования ссылок ДОЛЖНЫ удалить ссылки на Request-URI после утверждения пользователем». Здесь может быть достаточно места для маневра в словах «ожидается» и «ДОЛЖЕН». Не уверен, насколько хорошо 410 поддерживается / понимается клиентами.
• Вернуть HTTP-статус 200 и поле флага включения, указывающее, что ресурс удален. Это кажется странным, поскольку идея его удаления в первую очередь заключалась в том, что вы действительно хотели, чтобы он не появлялся.Это перекладывает ответственность за фильтрацию удаленных ресурсов на клиентов.

Параметры для ответов, которые включают этот удаленный ресурс:

• Пропустить ресурсы, объявленные как удаленные. Чисто и просто. Но что, если вы действительно хотите знать об удаленных ресурсах.
• Включите их вместе с полем, указывающим, что они удалены. Это перекладывает ответственность за фильтрацию удаленных ресурсов на клиентов. Это затрудняет разбиение на страницы, если вы хотите пролистывать только активные или удаленные ресурсы.

Параметры при обновлении ресурса, помеченного для удаления:

• Использовать HTTP-статус 404. Ресурс пропал? Но как отличить ресурс, помеченный как удаленный, от фактически удаленного? Тело HTTP в ответе 404 здесь может устранить неоднозначность, но тогда клиентам остается разобрать / интерпретировать ваше тело для устранения неоднозначности. Может быть, здесь может помочь заголовок ответа? Который из? Пользовательский заголовок?
• Использовать HTTP-статус 409 с сообщением о том, как сначала необходимо восстановить ресурс.

Параметры для отмены удаления ресурса, помеченного для удаления:

• Использовать HTTP PUT / POST для операции обновления ресурса и снова пометить его как активный. Это работает только до тех пор, пока вы не возвращаете HTTP 404 для операции GET для ресурса, поскольку он не выполняет PUT / POST для ресурса, который находится в состоянии «Не найден» (404).
• Используйте HTTP PUT / POST для операции создания ресурса. Проблема в том, какие данные имеют приоритет? Данные, отправленные в операции создания? Или данные, которые восстанавливаются? отфильтруйте его из любых других запросов, которые вернули бы его.Затем обработайте HTTP-запрос PUT / POST, который создает ресурс, как восстановленный, если идентификатор ресурса указывает на ресурс, помеченный как удаленный.
• Отдельный путь REST, выделенный для восстановления удаленных ресурсов, отмеченных для удаления.

Это далеко не полный список.Я просто хотел перечислить некоторые варианты, которые крутились у меня в голове.

Я знаю, что ответ на вопрос, как это сделать, как всегда, «зависит от обстоятельств». Что мне интересно, так это то, какие квалификации / требования вы бы использовали для принятия решения? Как вы это реализовали или реализовали сами?