Оверинженеринг при документировании ViewSets Django REST Framework

Только вот во 2-й ветке Django REST Swagger:

Deprecated:

YAML docstrings

И работает он теперь через CoreAPI и схемы. DRF предоставляет возможность ручного определения схем. И всё бы ничего, но повторять те же самые поля ещё раз?..

Возможность рисовать схему самому, но при этом таскать описания полей из имеющихся сериализаторов — это был бы не самый лучший, но выход. Можно попробовать покопаться в исходниках — rest_framework.schemas.SchemaGenerator и его get_path_fields, get_serializer_fields, get_pagination_fields и get_filter_fields, возможно, смогут помочь.

Оверинженеринг при документировании ViewSets Django REST Framework

По всей видимости, ощущение «неуклюжести» при использовании ViewSet'ов преследует многих, кто пытается ими пользоваться? ViewSet'ы, на мой взгляд, прекрасно подходят к случаю «один эндпоинт — одна модель, без отношений с другими». И совсем не подходят для сложных моделей с дополнительными action'ами. Выбор сериализатора на основании действия? Можно и так — делай соответствующий mixin и пользуйся им на здоровье. Выбор queryset'а? Ну, например, чтобы в list не тащить связанные модели, а вот в retrieve уже стянуть всё за один SQL-запрос — да тоже на здоровье.

Получаются они примерно такими - если кому интересно

# http://stackoverflow.com/questions/22616973/django-rest-framework-use-different-serializers-in-the-same-modelviewset
class MultipleSerializerViewSetMixin:

    def get_serializer_class(self):
        try:
            return self.action_serializer_classes[self.action]
        except (AttributeError, KeyError):
            return super().get_serializer_class()


class MultipleQuerysetViewSetMixin:

    def get_queryset(self):
        try:
            return self.action_querysets[self.action]
        except (AttributeError, KeyError):
            return super().get_queryset()

Теперь хочу фильтров! Разных! Тут становится понятно, что никакого «get_filters» нам не предоставлено — ну хорошо, переопределим filter_queryset, может даже полностью повторив его код — пускай… И где-то тут и возникает неловкость — как будто тебе дали рог изобилия, но забыли приложить к нему инструкцию и всё, что остаётся — лупить им по стенам и собирать вываливающиеся крошки.

Теперь что касается использования сразу get, post и т.д. Это в большинстве случаев скорее приятно, чем продуктивно. Знание того, что именно заставляет программу работать — оно прекрасно само по себе. Но постоянно переписывать одни и те же строчки для каких-то простых моделек?… Получение данных из request, валидация сериализатора, сохранение — и так 500 раз… А если я хочу в одну транзакцию с сохранением модели включить ещё что-то? Например, запись в журнал об этом изменении? Получается действительно много… даже Много повторяющегося кода. Причём повторяющего зачастую то, что в generic'ах уже кем-то написано, протестировано и упаковано — бери да пользуйся.

Так что по мне вариант — generic'и для сложных моделей, viewset'ы — для простых в две строчки. Есть конечно и свои нюансы — хочешь использовать меньше URL'ов и больше HTTP-методов — всё равно изволь выбирать сериализаторы… Но хотя бы не из простыни на 15 вариантов. Ну а get, post и остальные низкоуровневые методы — это для тех случаев, когда исполняемая логика не укладывается в обычный CRUD.