В чем разница ListAPIView и APIView в Django REST Framework

Что проверяют

Понимаете ли вы иерархию представлений в DRF и умеете ли выбрать уровень абстракции под задачу. Следом обычно спрашивают, как в ListAPIView отфильтровать данные по текущему пользователю и как подключить пагинацию.

Как отвечать

Покажите цепочку наследования, из неё разница видна сразу:

• APIView: наследник Django View. Добавляет объекты Request и Response, согласование формата, аутентификацию, permission_classes, throttle_classes и обработку исключений. Методы get(), post() и остальные вы пишете сами;
• GenericAPIView: наследник APIView. Добавляет queryset, serializer_class, get_queryset(), get_object(), get_serializer(), фильтрацию через filter_backends и пагинацию через pagination_class;
• миксины: ListModelMixin, CreateModelMixin и другие дают готовые методы list(), create();
• ListAPIView: это ListModelMixin плюс GenericAPIView с методом get(), который вызывает list(). Отвечает только на GET, а также на HEAD и OPTIONS.

Из этого следует выбор. ListAPIView берут для типового списка ресурсов: два атрибута дают выборку, сериализацию, фильтры и пагинацию. APIView берут для эндпоинтов, которые не ложатся на CRUD: агрегаты, запуск действия, ответ из нескольких источников. Если нужен и список, и создание, есть ListCreateAPIView, а полный набор операций удобнее собрать через ModelViewSet и роутер.

Для фильтрации по пользователю переопределяют get_queryset(), где доступен self.request.user.

Где спотыкаются

Пытаются отфильтровать по пользователю прямо в атрибуте класса queryset. Атрибут задаётся при объявлении класса, запроса там ещё нет.

Пишут APIView для обычного списка и вручную собирают пагинацию, фильтры и сериализацию, повторяя то, что ListAPIView уже умеет.

Забывают про права. Если в настройках не задан DEFAULT_PERMISSION_CLASSES, DRF по умолчанию использует AllowAny, и новый эндпоинт открыт всем.