backend-drf

Implements Django REST Framework endpoints with capability-based authorization and OpenAPI contracts.

Updated May 13, 2026
One-click install
npx skills add https://github.com/jcg-admin/kaupamex-api --skill backend-drf-jcg-admin
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: backend-drf
Source: https://github.com/jcg-admin/kaupamex-api/tree/main/.claude/skills/backend-drf
Command: npx skills add https://github.com/jcg-admin/kaupamex-api --skill backend-drf-jcg-admin

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires djangorestframework, djangorestframework-simplejwt, drf-spectacular, and includes references (resource) components.

What problem does it solve? Building consistent, secure DRF endpoints in the kaupamex e-commerce backend requires many project-specific decisions: FBV vs ViewSet vs CBV, capability-based authorization instead of plain IsAuthenticated, the codigo_error error canon, drf-spectacular annotations, and a no-lazy-imports gate. This Skill encodes all of those conventions so endpoints are implemented and verified correctly the first time. ## Core Features & Use Cases - View style decision guide: Phase-by-phase rules for choosing FBV (@api_view + @require_capability) for single actions, ViewSet + router for CRUD resources, or CBV APIView for legacy multi-method cases. - Capability-based authorization: Enforces HasCapability (fail-closed) with permission_map, seed_authz catalog registration, and DEC-12 re-auth for sensitive mutations. - 28 on-demand references: Dedicated docs for requests, responses, serializers, permissions, throttling, pagination, filtering, exceptions, testing, and the REST_FRAMEWORK settings map. - Use Case: When adding a new endpoint like an address CRUD resource, the Skill directs you to a ModelViewSet with router registration, permission_map gating, @extend_schema annotations, explicit pagination_class, and pytest-django tests against real PostgreSQL. ## Quick Start Use the backend-drf skill to implement a new DRF endpoint for the kaupamex API with capability authorization and OpenAPI annotations.

Frequently Asked Questions about backend-drf

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose between FBV, ViewSet, and APIView in Django REST Framework?▼

Use an FBV with @api_view for a single action (one verb), a ViewSet or ModelViewSet with a router for a CRUD resource, and a CBV APIView only for legacy multi-method cases that are not CRUD resources. ViewSets must always be wired through a router, never manual .as_view({...}) binding.

How do I implement permission-based authorization in DRF beyond IsAuthenticated?▼

Use a custom BasePermission subclass like HasCapability that resolves a capability code per action and fails closed with 403 when undeclared. Combine it with permission_map on ViewSets or a @require_capability decorator on FBVs, and register new capability codes in the seed catalog.

Does DRF pagination apply automatically to all list endpoints?▼

No. Without a DEFAULT_PAGINATION_CLASS in settings, a list view returns the entire queryset unless it declares a pagination_class. Plain APIView handlers must paginate manually via paginate_queryset and get_paginated_response.

Why does my DRF endpoint return 403 instead of 401 for anonymous users?▼

DRF only returns 401 when an authenticator provides a WWW-Authenticate header via authenticate_header(). SessionAuthentication does not, so anonymous requests get 403; overriding authenticate_header to return a scheme forces the correct 401 response.

How do I document DRF endpoints with OpenAPI using drf-spectacular?▼

Annotate each endpoint with @extend_schema including tags, summary, request serializer, and response descriptions, and set DEFAULT_SCHEMA_CLASS to drf_spectacular AutoSchema. The schema is then served at /api/schema/ with Swagger UI and Redoc views.

When should I not use cache_page for caching DRF responses?▼

Avoid cache_page on per-user endpoints with session authentication, because caching by URL can leak one user's data to another unless you add @vary_on_cookie. Prefer low-level cache.get/cache.set with a namespaced key that includes the inputs determining the result.