Django 5.2+ teams get an API layer that still feels like Django
Django REST Framework 3.18.1 turns Django models and ordinary Python objects into HTTP APIs through serializers, views, authentication classes, permissions, and content negotiation. Viewsets and routers can remove repetitive URL and CRUD code, while function-based views remain available when those abstractions are too broad. The browser interface is more than decoration for an internal API: a developer can inspect responses, authentication behavior, forms, and errors without first building a separate client.
The measured checkout was 15.5 MB before installation, with 585 files and roughly 42,184 lines of source. That is substantial middleware rather than a thin JSON helper. It covers model and non-model serializers, generic views, pagination, filtering hooks, versioning, schemas, and several authentication styles. The trade is a vocabulary of fields, mixins, viewsets, renderers, parsers, and settings that a team must understand when a default stops matching its API.
What happened when we ran it
Our sandbox installed 39 packages in 31 seconds and occupied 78 MB on disk. The build completed in 2 seconds at commit b92edf5. We used an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The repository scan found 4 CI workflow files and a tests directory, but no Dockerfile. Pip-audit reported 0 known vulnerabilities in the installed Python packages.
Pytest failed with exit 4 after 2 seconds while importing tests/conftest.py. The final error was ModuleNotFoundError: No module named 'dj_database_url', so the suite stopped before it could report passing or failing cases. The same commit lists dj-database-url>=3.1.0 in its test dependency group, and tox selects that group. Our run proves the tested install path lacked the module; it does not show how the REST Framework assertions would finish after that dependency is present.
Version 3.18.1 removes boilerplate, not database decisions
DRF 3.18.1 can derive serializer fields from a Django model, validate incoming data, and connect a viewset to generated routes. That is a large reduction in repeated endpoint code. It also makes nested representations and related fields easy to express. The framework does not pretend those declarations are free. A serializer may touch relations while producing each item, and the API author still controls the queryset that feeds it.
DRF 3.18.1 explicitly declines to add select_related or prefetch_related automatically because doing so would introduce hidden behavior. Its relations guide warns that a field crossing an ORM relation can cause another database hit for each object unless the queryset is prepared. That is the right design for predictability, but it means performance review belongs beside serializer review. A concise ModelSerializer can still back an expensive list endpoint.
Version 3.18.1 permissions do not filter every object for you
In DRF 3.18.1, object permission checks run when a generic view retrieves one object through get_object(). The documentation says generic list views do not call the object check for every row because of the cost. You must filter the queryset so users cannot see objects outside their scope. Object checks also do not protect creation automatically, so create policy belongs in the serializer or perform_create() implementation.
Built-in throttling has a similarly clear boundary. DRF says its cache-based counters use non-atomic operations, so request rates may be fuzzy under concurrency. The project does not present them as protection against brute force or denial-of-service attacks because clients can spoof origin addresses. Use them for product tiers and basic over-use policy. Put hard traffic controls, abuse detection, and capacity protection at a layer designed for hostile traffic.
Version 3.18.1 is current, while the core is feature-complete
Release 3.18.1 shipped on September 7, 2026 with fixes for duplicate IP validation errors, negative integer OpenAPI formats, list serializer uniqueness, and non-finite float values. Version 3.18.0 had arrived one month earlier with Django 6.1 support and dropped Django 4.2, 5.0, and 5.1. That pace shows active compatibility work. It also means teams upgrading a mature application should read release notes for changed validation and error formats.
GitHub showed 30,182 stars and 50 combined open issues and pull requests when fetched, with 27 of those entries being issues. The last push was September 15, 2026, and current pull requests were still being updated that day. The contributing guide describes the project as essentially feature-complete and discourages new features. Read that as maintenance focus, not neglect: Django compatibility and bug fixes continue, while a speculative extension may belong outside core.
The 78 MB install earns a Django trial, not a framework migration
Our 78 MB environment built in 2 seconds, so trying DRF inside an existing Django application is inexpensive even though the test dependency path needs care. Its strongest case is continuity: Django models, authentication, permissions, and settings stay in charge while DRF handles API representation and request flow. Do not move a non-Django service onto Django only to obtain DRF. For a Django codebase, start with one real endpoint and inspect its SQL, list visibility, create permissions, and edge throttling before standardizing on it.