django-drf_skill
198
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill gentleman-programming/gentleman-skills --skill django-drf- SKILL.md4.5 KB
Overview
This skill provides concise, battle-tested Django REST Framework patterns for building REST APIs with ViewSets, Serializers, Filters, Permissions, Pagination, routing, and tests. It focuses on pragmatic defaults and clear separation of read/create/update serializers and reusable components to speed development and reduce bugs.
How this skill works
The skill supplies example ViewSet patterns with action-based serializer selection and custom actions, serializer templates for read/create/update use cases, and filter definitions using django-filter. It also includes permission classes, pagination configuration, router-based URL registration, and pytest examples for API tests so you can plug patterns into a project quickly.
When to use it
- When building CRUD APIs with Django and DRF using ViewSets and routers
- When you need separate serializers for read, create, and update operations
- When you want consistent filtering, pagination, and permission behavior across endpoints
- When writing automated API tests with pytest and DRF test client
- When adding custom actions (e.g., activate) to resources
Best practices
- Use ModelViewSet with get_serializer_class to return action-specific serializers
- Keep read-only fields in read serializers and write-only fields (like password) in create serializers
- Centralize filters in FilterSet classes and expose only safe fields
- Write small, focused permission classes (owner/admin patterns) and attach them to viewsets
- Configure a standard pagination class in settings to keep responses consistent
- Cover key endpoints with pytest tests using APIClient and force_authenticate
Example use cases
- User management endpoints with activation action, separate create/update serializers, and name formatting
- Resource lists that support email contains, active flag, and created_at range filters
- Admin vs read-only access control for collections and owner-restricted object access
- Paginated list views with page_size query control and sane defaults
- Automated tests for list and create operations to prevent regressions
FAQ
Expose password as write-only in the create serializer, call set_password in create(), and never return it in read serializers.
When should I split serializers by action?
Split when read and write shapes differ (computed fields, read-only metadata, or write-only sensitive fields) to keep validation and output explicit.