Validated Learning-Progress REST API

1. Project setup and API contract

Scenario: build the real backend behind a learning platform's course and progress tracking. Set up a fresh Express project (npm init -y, npm install express, "type": "module") with a feature-organized structure: src/routes/, src/services/, src/middleware/, src/config.js, src/errors.js, src/server.js. Document your planned API contract before writing routes: GET/POST /courses, GET/PATCH/DELETE /courses/:id, GET/POST /progress, GET/PATCH /progress/:id, GET /health — with the exact request/response shape for each.

• The project structure separates routes, services, middleware, and configuration into their own files/folders
• A written API contract exists (even as a comment or README) documenting every endpoint's method, path, request shape, and success response shape before implementation begins
• package.json has "type": "module" and express installed as a real dependency

2. Resources, validation, and structured errors

Implement the courses and progress resources with their full CRUD-appropriate routes, following this course's REST design lesson (correct status codes: 201 for create, 204 for delete, 404 for missing resources). Extract business logic into a service layer per resource. Add real validation for every write endpoint (POST/PATCH), collecting all errors per request, and a centralized error-handling middleware using a shared AppError class distinguishing operational from programmer errors.

• Every write endpoint validates its input and returns 400 with a structured, field-specific error body for invalid data
• GET requests for a nonexistent resource id return 404, not a generic error or a 200 with null data
• A single centralized error-handling middleware (4 parameters, registered last) handles every error, hiding programmer-error details behind a generic message
• Route handlers call service functions rather than embedding business logic directly in the route

3. Configuration, logging, and security boundaries

Add startup configuration validation (required environment variables checked before the server starts, failing fast with a clear message naming every missing value) and a safe logging utility that redacts sensitive fields before writing anything out. Add an authorization-check middleware for at least one endpoint that should be restricted, correctly distinguishing 401 (no valid identity) from 403 (valid identity, insufficient permission) using a simulated/mocked identity for this project's purposes (not a real credential system).

• The server refuses to start with a clear, specific error if required configuration is missing
• A logging utility redacts at least password/token-style fields before anything is logged, and is used consistently rather than ad hoc console.log calls
• At least one endpoint has an authorization check that correctly returns 401 for no identity and 403 for a valid-but-unauthorized identity

4. Automated tests

Add an automated test suite (using the test runner from this course's testing lesson) covering: at least three service-level tests (including at least one rejection/error case), at least three HTTP-level tests using supertest against the exported Express app (including at least one validation-failure case expecting 400), and confirm the full suite is properly isolated (each test sets up its own fresh state).

• At least three service-level tests exist, including a case that should fail/reject
• At least three HTTP-level tests exist using supertest, including a validation-failure case
• Every test creates its own fresh state rather than depending on another test's leftover data
• The full test command runs successfully with zero failures

5. Operational readiness

Add a GET /health endpoint reporting real readiness (not just 'the process is running'), and implement graceful shutdown: on SIGTERM, stop accepting new connections, let in-flight requests finish, then exit — following this course's operational-readiness lesson.

• GET /health returns a meaningful status distinct from simply 'the process didn't crash'
• The server calls server.close() (or equivalent) on SIGTERM rather than exiting immediately
• Manually verified: starting the server, sending a slow request, then triggering shutdown does not abruptly cut off that in-flight request