Comments 9
лучше воспользоваться вместо этого методом PUT с телом, включающим в себя что-то вроде {status: 'deleted'}.
Но ведь метод PUT должен принимать весь объект целиком? Для частичного изменения предусмотрен метод PATCH, или я ошибаюсь?
PATCH — частичное обновление записи
PUT — полное обновление объекта
Правда, в контексте статьи неважно о каком методе шла речь.
На всякий случай, переправил PUT на PATCH, чтобы это не вызывало у людей недоумения.
Хотя, стандарт определяет, что сохранять надо именно под URL запроса:
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server.
Так что ещё раз: вы правы.
Все правильно на такую мелочь не надо генерировать вьюшку.
Тот же EF имеет Global Filters. С моей точки зрения полезность их сомнительна, но вам подойдет.
Также кто вам мешает понаписывать экстеншины или хелпер методы
public static IQueryable<Document> ValidDocuments(this DbContext ctx)
=> ctx.Documents.Where(d => d.Deleted != null);
Из минусов вижу что инклюдо-писание пострадает (Include/ThenInclude)
Если история очень важна, то можете хранить в таблице EffectiveStart, EffectiveEnd и считать что записи нет если EffectiveEnd установлена в дату меньше необходимой
public static IQueryable<Document> ValidDocuments(this DbContext ctx, DateTime onDate)
=> ctx.Documents.Where(d => d.EffectiveStart <= onDate && (d.EffectiveEnd == null || d.EffectiveEnd > onDate));Но опять же страдает инклюдописание, что-то тут недодумали. Так бывает когда продукт пишут те кто его полноценно не использует (sarcasm)
public static IQueryable<Document> ValidDocuments(this DbContext ctx)
=> ctx.Documents.Where(d => d.Deleted != null);Эмм… Так я же так и делаю! Вьюшка или глобальный фильтр мне не подошли.
Но насчёт детского сада вы, может быть, и правы.
Разумеется, ничего принципиально нового в этой статье нет. Просто я считаю, что моя цель достигнута, если хотя бы паре человек это пригодится.
Главная идея здесь — интерпретация метода DELETE как перемещения ресурса в архив. В начале работы это было совсем неочевидно.
{Восстанавливает удалённый документ;не требует тела; возвращает 201 Created}
Почему решено использовать 201 код? Ведь ресурс не создавался, была выполнена операция по восстановлению. Не кажется что 200 более уместно?
Используется метод POST, и response 201 содержит location со ссылкой на воссозданный объект. Это как корзина: если восстановить файл, он вновь появится в своей папке, а до этого его там не было. Так что можно рассматривать эту операцию как создание ресурса.
В принципе, можно и 200 использовать, но тогда придётся вернуть сам объект: rest - Create request with POST, which response codes 200 or 201 and content - Stack Overflow .
Мягкое удаление в REST API