GO — Healthy across the board

• Last commit 2d ago
• 43+ active contributors
• Distributed ownership (top contributor 24% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against dependency CVEs from deps.dev and OpenSSF Scorecard}

Django REST framework is a robust toolkit for building Web APIs on top of Django that handles serialization, authentication, permissions, pagination, and content negotiation. It provides a browsable web interface for API exploration and supports both ORM and non-ORM data sources through its flexible serializer system, making it the de facto standard for REST API development in Django projects. Monolithic package structure: rest_framework/ is the core library containing serializers/ (fields.py, relations.py), permissions/, authentication/, views/, routers/, and parsers/. docs/ is the comprehensive MkDocs-based documentation. Tests are alongside source code. No monorepo complexity—single self-contained Django app designed as a drop-in INSTALLED_APPS addition.

Django backend engineers and teams building production web APIs who need batteries-included tooling for authentication (OAuth1/2), request/response handling, and API documentation without building these components from scratch.

Highly mature and production-ready. The project supports Python 3.10+ and Django 4.2–6.0, has extensive test coverage (visible in codecov.yml), active CI/CD pipelines (.github/workflows), and well-organized documentation. It's a foundational package in the Django ecosystem with millions of downloads and continuous maintenance.

Low risk for stability but moderate maintenance risk: single primary maintainer (Tom Christie) with a large active issue backlog typical of popular OSS projects. The broad Django version support matrix (4.2–6.0) requires careful testing across versions. No major breaking changes expected in 3.x series, but integrations with third-party auth packages (OAuth1/2) add dependency management complexity.

Active maintenance with focus on Django version compatibility (6.0 support added). Workflow automation via GitHub Actions (main.yml, mkdocs-deploy.yml, release.yml) handles CI and documentation publishing. Dependabot configured for dependency updates. Documentation is the primary active area with versioning support and new API guide pages being added.

git clone https://github.com/encode/django-rest-framework.git
cd django-rest-framework
pip install -e .
pip install -e '.[dev]'  # Install development dependencies
python runtests.py  # Run test suite

Daily commands: After installation: python manage.py runserver in a Django project with DRF in INSTALLED_APPS. For testing the example: create Django project, add rest_framework to INSTALLED_APPS, wire up routers (see README example), then ./manage.py migrate && ./manage.py createsuperuser && ./manage.py runserver.

• rest_framework/serializers.py: Core serialization logic: Serializer base class, ModelSerializer ORM integration, field validation pipelines—foundational to all API data handling
• rest_framework/views.py: APIView class and request/response cycle: handles content negotiation, exception rendering, and authentication/permission checks—entry point for all requests
• rest_framework/routers.py: ViewSet routing: DefaultRouter and SimpleRouter auto-generate URL patterns from ViewSet methods—critical for URL configuration in example/README
• rest_framework/generics.py: Generic class-based views (ListCreateAPIView, RetrieveUpdateDestroyAPIView): combine ViewSet logic with Mixin composition for CRUD APIs
• rest_framework/fields.py: Field classes for serializers: IntegerField, CharField, RelatedField, PrimaryKeyRelatedField—defines data types and validation on serialized output
• rest_framework/authentication.py: Authentication backends: TokenAuthentication, SessionAuthentication, BasicAuthentication—pluggable auth system used in permission checks
• rest_framework/permissions.py: Permission classes: IsAuthenticated, IsAdminUser, DjangoObjectPermissions—declarative access control tied to APIView.permission_classes
• tests/: Comprehensive test suite mirroring source structure: critical for validating changes across Python 3.10+ and Django 4.2–6.0 version matrix
• docs/api-guide/: Official documentation: docs/api-guide/serializers.md, docs/api-guide/views.md, docs/api-guide/authentication.md are the primary learning/reference materials

Serializers (data transformation): edit rest_framework/serializers.py and rest_framework/fields.py. Views & routing: rest_framework/views.py, rest_framework/generic.py, rest_framework/routers.py. Authentication/permissions: rest_framework/authentication.py, rest_framework/permissions.py. Parsers/renderers: rest_framework/parsers.py, rest_framework/renderers.py. New feature tests: add to tests/ with corresponding source in rest_framework/.

1. Django version pinning: Tests must pass against Django 4.2, 5.0, 5.1, 5.2, AND 6.0—settings.py and view behavior changes per version. 2. ORM caching gotcha: ModelSerializer caches field introspection; changing model fields requires server restart in dev. 3. Content negotiation precedence: Accept header, format_suffix_patterns, and default renderer interact unintuitely—query param ?format=json overrides Accept. 4. Circular import risk: rest_framework/serializers.py imports from views.py and vice versa for Hyperlink fields—watch import order in new modules. 5. Permission checking happens late: is_authenticated is checked in permission_classes, not init—unauthenticated requests still enter dispatch().

• Content Negotiation — DRF automatically serializes responses to JSON, HTML, XML, or YAML based on Accept headers and format_suffix_patterns—understanding this is critical to controlling API output format
• Serializer Field Validation — DRF's layered validation (field-level via validators, object-level via validate()) prevents invalid data at API boundaries—learning this prevents data corruption bugs
• ViewSet Mixins & Action Routing — ViewSets combine multiple Mixins (CreateModelMixin, ListModelMixin, etc.) and route HTTP methods to actions—mastering this enables concise CRUD API code
• Permission & Authentication Pipeline — DRF chains authentication backends, permission classes, and throttle classes in check_permissions()—understanding execution order prevents security gaps
• HyperlinkedModelSerializer Relationships — DRF's auto-generation of URL-based relations (PrimaryKeyRelatedField vs StringRelatedField) requires understanding reverse() and URL namespacing—critical for REST HATEOAS compliance
• Request & Response Objects — DRF wraps Django's HttpRequest/HttpResponse into Request/Response with built-in parser/renderer selection—shadowing these can break content negotiation
• Token Bucket Rate Limiting (Throttling) — DRF implements throttling (UserRateThrottle, AnonRateThrottle) to prevent API abuse—configuring REST_FRAMEWORK['DEFAULT_THROTTLE_RATES'] is essential for production APIs

• django/django — Core dependency: DRF extends Django's CBV architecture and integrates with Django ORM, auth, and middleware
• encode/django-filter — Companion package by same org: provides FilterSet integration for queryset filtering in DRF generic views via filter_backends
• jpadilla/django-rest-framework-jwt — Third-party auth extension for JWT token support, commonly used alongside DRF's TokenAuthentication
• carltongibson/django-cors-headers — Peer ecosystem tool: enables CORS in Django APIs built with DRF to allow cross-origin requests
• graphene-python/graphene — Alternative API paradigm: GraphQL support for Django as a contrast to DRF's REST approach

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for schema generation with custom field types

The docs/api-guide/schemas.md documentation exists but there's no dedicated test module for schema generation edge cases. DRF's schema system is complex and handles many field types, validators, and custom serializers. A new test file would ensure schema generation works correctly across all field combinations, especially for custom fields and nested serializers which are frequently sources of bugs.

• [ ] Create tests/test_schemas_advanced.py to test schema generation for: custom field types, nested relationships, read_only/write_only fields, and validators
• [ ] Add tests for schema generation with various authentication classes and permission classes
• [ ] Test schema generation for viewsets with custom actions and multiple serializer classes
• [ ] Ensure coverage for edge cases like circular relationships and deeply nested structures

Add workflow for testing against multiple Django/Python version combinations in isolation

The .github/workflows/main.yml exists but a review of DRF's CI would benefit from explicit testing of the minimum supported versions vs latest versions. Given DRF's broad compatibility requirements (Django 3.2+ and Python 3.8+), adding a matrix-based workflow that explicitly tests corner cases would catch compatibility regressions early.

• [ ] Review current .github/workflows/main.yml to identify tested version combinations
• [ ] Create or enhance .github/workflows/compatibility.yml with a full matrix: Python 3.8/3.9/3.10/3.11/3.12 × Django 3.2/4.0/4.1/4.2/5.0
• [ ] Include tests for minimum dependency versions (e.g., oldest supported cryptography for JWT backends)
• [ ] Add workflow to test optional dependencies: JWT, YAML, XML renderers, and markdown rendering

Document and add tests for pagination edge cases and custom cursor/offset behavior

The docs/api-guide/pagination.md exists but the test coverage for edge cases in pagination (empty querysets, single items, extreme limit values, custom orderings) appears incomplete. This is a high-value area since pagination bugs affect API usability and can cause data exposure issues.

• [ ] Create tests/test_pagination_edge_cases.py covering: empty results, single item, limit=0, negative limits, non-existent page numbers
• [ ] Add tests for CursorPagination with custom orderings, non-unique ordering fields, and reverse ordering
• [ ] Test pagination behavior with filtered querysets and custom get_paginated_response() overrides
• [ ] Document pagination best practices in docs/api-guide/pagination.md with explicit examples for handling edge cases and security considerations

• Add comprehensive docstring examples to rest_framework/fields.py for each field type (IntegerField, DateTimeField, JSONField, etc.) showing real-world validation scenarios—docs/api-guide/fields.md references these but source lacks inline examples
• Create a test file tests/test_content_negotiation_edge_cases.py covering interactions between Accept headers, format_suffix_patterns, and ?format query params across all built-in renderers (JSONRenderer, BrowsableAPIRenderer, TemplateHTMLRenderer)—current tests are scattered
• Document the ViewSet-to-URL routing process in docs/api-guide/routers.md with a step-by-step diagram showing how DefaultRouter maps list/create/retrieve/update/destroy actions to HTTP verbs and paths—common confusion point for newcomers

Django REST Framework demonstrates reasonable security practices with a defined security reporting policy and automated dependency management through Dependabot. However, the analysis is limited by the absence of visible dependency files for vulnerability assessment. The project shows good governance patterns (signed releases, pre-commit hooks, CI/CD workflows) but could strengthen its security posture by: (1) providing visible dependency manifests for automated analysis, (2) enhancing security policy documentation with disclosure timelines, and (3) implementing code signing practices. No obvious hardcoded secrets, injection vulnerabilities, or misconfigurations were detected in the visible file structure. The main security concern is the inability to audit dependencies without access to package manifests.

• Medium · Missing dependency pinning in version control — Repository root - missing dependency manifest. No package dependency file (requirements.txt, setup.py, pyproject.toml, etc.) was provided for analysis. This makes it impossible to verify that the project uses secure, non-vulnerable versions of its dependencies. Unspecified or outdated dependencies could introduce known security vulnerabilities. Fix: Ensure all dependencies are explicitly listed with pinned versions in a requirements.txt, setup.py, or pyproject.toml file. Regularly audit dependencies using tools like pip-audit or Dependabot for known vulnerabilities.
• Low · Incomplete security policy documentation — SECURITY.md. The SECURITY.md file contains a security contact email but lacks details on vulnerability disclosure timeline, scope, and acknowledgment process. Best practices recommend defining expected response times and whether security researchers will be credited. Fix: Expand SECURITY.md to include: expected response timeline, scope of what is/isn't considered a vulnerability, responsible disclosure guidelines, and whether CVE assignments are available.
• Low · No Code Signing or Integrity Verification — Repository root. The repository structure does not show explicit code signing mechanisms, signed commits, or checksum verification files. This could make it susceptible to supply chain attacks if the repository is compromised. Fix: Implement GPG signing for releases, enable signed commits in GitHub, and consider publishing checksums/signatures for release artifacts. Document these verification steps for users.
• Low · Dependabot configuration present but not fully reviewed — .github/dependabot.yml. While .github/dependabot.yml exists (indicating automated dependency updates), the actual configuration content is not visible. It's unclear if auto-merge is enabled or if all package managers are covered. Fix: Review Dependabot configuration to ensure: security updates are auto-merged or auto-reviewed, all package managers are covered, and pull request limits aren't too high to cause review fatigue.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/encode/django-rest-framework shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live encode/django-rest-framework repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/encode/django-rest-framework.

What it runs against: a local clone of encode/django-rest-framework — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in encode/django-rest-framework | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 32 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of encode/django-rest-framework. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/encode/django-rest-framework.git
#   cd django-rest-framework
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of encode/django-rest-framework and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "encode/django-rest-framework(\\.git)?\\b" \\
  && ok "origin remote is encode/django-rest-framework" \\
  || miss "origin remote is not encode/django-rest-framework (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 32 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/encode/django-rest-framework"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.