backend-drf-spectacular

Annotate the view method with @extend_schema, providing summary, parameters via OpenApiParameter, responses per status code, and a tag matching your app's SPECTACULAR_TAGS. Place the decorator on the actual entry method like get or post, not on list or retrieve.

Create a schema.py in the app declaring SPECTACULAR_TAGS and any extensions. The project's PREPROCESSING and POSTPROCESSING hooks collect tags and register extensions automatically, so you never edit the global SPECTACULAR_SETTINGS in base.py.

This warning signals failed introspection, usually a missing extension for custom authentication or a third-party serializer. Fix it by writing an OpenApiAuthenticationExtension, OpenApiSerializerExtension, or OpenApiViewExtension in the app's schema.py.

Add an entry to ENUM_NAME_OVERRIDES in SPECTACULAR_SETTINGS mapping the colliding choice set to a fixed component name. Do not rename the model choices themselves to solve a schema-level naming problem.

Yes, but simplejwt's views need extensions because introspection fails on the overridden validate method and empty logout response. The project uses an OpenApiSerializerExtension for login and an OpenApiViewExtension for logout.

Avoid it when you can annotate the method directly, which is the project convention. Reserve @extend_schema_view for methods you do not override, such as inherited ViewSet actions or multi-method @api_view functions.