Мы с вами немножко о разной валидации говорим. Я считаю, что сериализатор должен проверять только корректность формата запроса, но не его логическую правильность по отношению к текущему состоянию БД. DRF позволит написать любую логику касающуюся моделей в сериализаторе (например ваша проверка могла бы быть в методе FooSerializer.validate()) и я периодически вижу, что люди пишут подобный код, но я бы не сказал что это что-то хорошее. На мой взгляд задача сериализатора проверить, что в запросе есть список идентификаторов (или любой другой набор полей) записей которые пользователь хочет восстановить. А уже менеджер модели занимался бы всем, что касается БД в процессе восстановления.
Также всегда в ситуации, когда мы что-то проверяем по БД, а потом на основе этого что-то изменяем появляется вероятность, что между этими двумя событиями результат проверки может измениться, в данном случае проблему можно решить используя SELECT FOR UPDATE. В случае проверки в сериализаторе, а выполнения действия восстановления где-то еще мы размазываем знание об обработке этого запроса по разным частям кода (не говоря о том, что транзакцию придется начать в сериализаторе а закрыть где-то еще), что на мой взгляд не есть хорошо.
напишите сериалайзер для восстановления записи из soft delete если есть уникальные поля.
Не думаю что сериализаторы должны заниматься чем-то кроме сериализации и валидации данных, соответственно логика восстановления из soft delete просто не их зона ответственности. Я предложил бы реализовать эту логику в кастомном менеджере модели.
На мой взгляд лучше иметь четкую схему ответа на запрос, чтобы пользоваться всеми преимуществами swagger/openapi и предоставлять контракт для клиентских приложений, что как раз подходит под описанный вами кейс API для мобильного приложения. Еще замечу, что этот пример не предполагает разных представлений модели User для разных View. Соответственно чтобы получить такую возможность все равно придется что-то дописывать. При желании в Django можно написать похожий код (для соответствия вашему примеру все же придется написать обертку в несколько строк над встроенной возможностью сериализации моделей)
Также всегда в ситуации, когда мы что-то проверяем по БД, а потом на основе этого что-то изменяем появляется вероятность, что между этими двумя событиями результат проверки может измениться, в данном случае проблему можно решить используя SELECT FOR UPDATE. В случае проверки в сериализаторе, а выполнения действия восстановления где-то еще мы размазываем знание об обработке этого запроса по разным частям кода (не говоря о том, что транзакцию придется начать в сериализаторе а закрыть где-то еще), что на мой взгляд не есть хорошо.
На мой взгляд лучше иметь четкую схему ответа на запрос, чтобы пользоваться всеми преимуществами swagger/openapi и предоставлять контракт для клиентских приложений, что как раз подходит под описанный вами кейс API для мобильного приложения. Еще замечу, что этот пример не предполагает разных представлений модели User для разных View. Соответственно чтобы получить такую возможность все равно придется что-то дописывать. При желании в Django можно написать похожий код (для соответствия вашему примеру все же придется написать обертку в несколько строк над встроенной возможностью сериализации моделей)
P.S. С PHP и RoR не знаком