Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Build a REST API with Django REST Framework over a small domain (a library, a store, an issue tracker). Requirements: model the domain with relationships; expose it through SERIALIZERS (ModelSerializer) and VIEWSETS registered on a router (auto-generated RESTful routes); add authentication (Token or Session) and PERMISSION classes (IsAuthenticated or IsAuthenticatedOrReadOnly so writes are gated but reads may be open); query the ORM efficiently — filter with field lookups (name__icontains) and AVOID N+1 with select_related (FK/OneToOne) and prefetch_related (ManyToMany/reverse FK); enable pagination; and write a couple of tests using the DRF APITestCase/test client. Explain one concrete place select_related vs prefetch_related mattered.
ModelSerializers + ViewSets on a router give clean RESTful CRUD; pagination configured; the browsable API works.
Authentication (Token/Session) plus permission classes correctly gate writes vs reads (IsAuthenticated / IsAuthenticatedOrReadOnly).
Field-lookup filtering; N+1 avoided with select_related/prefetch_related (choice justified); tests exercise the endpoints via the DRF client.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A JSON API with Django REST Framework ## Goal Build a REST API with Django REST Framework over a small domain (a library, a store, an issue tracker). Requirements: model the domain with relationships; expose it through SERIALIZERS (ModelSerializer) and VIEWSETS registered on a router (auto-generated RESTful routes); add authentication (Token or Session) and PERMISSION classes (IsAuthenticated or IsAuthenticatedOrReadOnly so writes are gated but reads may be open); query the ORM efficiently — filter with field lookups (name__icontains) and AVOID N+1 with select_related (FK/OneToOne) and prefetch_related (ManyToMany/reverse FK); enable pagination; and write a couple of tests using the DRF APITestCase/test client. Explain one concrete place select_related vs prefetch_related mattered. ## Acceptance criteria - [ ] API design: ModelSerializers + ViewSets on a router give clean RESTful CRUD; pagination configured; the browsable API works. - [ ] Auth & permissions: Authentication (Token/Session) plus permission classes correctly gate writes vs reads (IsAuthenticated / IsAuthenticatedOrReadOnly). - [ ] ORM efficiency & tests: Field-lookup filtering; N+1 avoided with select_related/prefetch_related (choice justified); tests exercise the endpoints via the DRF client. ## Verification - [ ] Document installation and run commands. - [ ] Record automated checks and their exact commands. - [ ] Add representative output, screenshots, or a short demo where useful. - [ ] Confirm failure paths and known constraints. ## Decision log ### Decision title - Context: - Choice: - Alternatives considered: - Tradeoffs: ## Evidence - Link each rubric criterion to the file, test, or artifact that demonstrates it. ## Known limitations - List what is intentionally out of scope and what should be improved next.