QAP 2 - Habit Tracker REST API

QAP 2 - Habit Tracker REST API

Objective

Build a small REST API with Express that lets a user manage daily habits (e.g., “Drink Water”, “Exercise”). The app should have full CRUD endponts with proper input validation and error handling.

Due date: February 17th, 2026 at 11:59PM

Getting Started

  • To help you get started, a base repository has been provided for you to work from. The repository is set up as a GitHub Assigment to help you quickly get started.

Steps to Create Your Own Repository

  1. Click the GitHub Classroom assignment link and choose your name.
  2. Click “Accept this assignment.”
  3. Clone your newly created repository:
    git clone <your-new-repo-url>
  4. Navigate to the folder and install dependencies:
    cd <your-new-repo-name>
    npm install
  5. Start the app:
    npm start

Requirements

Technology Requirements

  • Your application must run on Node.js using Express for the backend.
  • All data must be stored in-memory (e.g., arrays/objects in JavaScript). Assume only one user uses the API at a time.
  • No database, ORMs, or external services are required or expected.
  • You are allowed to use additional npm packages to enhance your application. However, ensure that any extra packages are relevant and add value to your project. Please note, outside of express no external packages should be required for this project.
  • The project is API-only. No frontend or templating engine is required.

Application Requirements

You will build an API that manages habits and allows for daily habit checkins

Habit Model

Each habit should have at least:

  • id (string or number, unique per habit)
  • name (string, required, e.g., “Drink Water”)
  • description (string, optional)
  • targetPerWeek (number, required, e.g., 3 times per week)
  • createdAt (date or string, set when created)

Check-in Model

A “check-in” represents the user completing a habit on a given day.

Each check-in should have at least:

  • id (string or number, unique per check-in)
  • habitId (must reference an existing habit)
  • date (string in YYYY-MM-DD format)
  • completed (boolean, default true)

You can add other fields to your models if you wish, but they’re not required.

Required API Endpoints

On top of the particular routes required, each route should (where necessary):

  • Return JSON responses for successful requests
  • Include proper error handling and input validation
  • Use proper HTTP status codes for failed requests
  • Have a consistent error response across the API (i.e. each error returns JSON with an error field).

The particular error handling/validation required for each route is up to you to figure out

Habit Routes

  • GET /habits

    • Returns a list of all habits.
  • GET /habits/:id

    • Returns a single habit by id
  • POST /habits

    • Creates a new habit via the provided JSON body
  • PUT /habits/:id

    • Performs a complete replacement of the habit with the provided ID using the data provided in the JSON body
  • DELETE /habits/:id

    • Deletes a habit and its related check-ins

Check-in Routes

  • GET /habits/:habitId/checkins

    • Returns all check-ins for a specific habit
  • POST /habits/:habitId/checkins

    • Creates a new check-in for a specific habit

You are free to add additional endpoints (e.g., to get a weekly summary) if you want, as long as the required ones are implemented correctly.

Error Handling Requirements

  • You must design and use appropriate HTTP status codes for both success and error scenarios.
  • Error responses (body format, fields, messages) must be consistent across the API.
  • You are free to choose how errors are represented and handled (JSON structure, fields, etc.), but:
    • The format should be the same for all error responses.
    • The status codes should clearly communicate the type of problem.

Submission

  • Ensure the app runs with npm start.
  • Submit the assignment by providing the link to your GitHub Classroom repository on Teams under the appropriate assignment.
  • Submissions are subject to the Keyin late assessment policy found here
    • If an extension is needed, please reach out to me directly before the assignment due date.

Grading Rubric

CategoryCriteriaPoints
API Functionality40
    Habit EndpointsAll required /habits CRUD endpoints implemented and working.20
    Check-in EndpointsCheck-in routes work and correctly relate to habits.10
    JSON ResponsesSuccessful responses return JSON with a clear structure.10
Correctness & Error Handling25
    Validation LogicInput handling behaves correctly for valid and invalid data.10
    Status CodesStatus codes are appropriate, intentional, and well-chosen.10
    Error ConsistencyError responses are consistent in format across all endpoints.5
Business Logic & Design10
    In-Memory DataHabits and check-ins are tracked correctly during runtime.10
Code Quality10
    ReadabilityCode is clean, consistent, and logically organized.5
    MaintainabilitySensible naming, small functions, minimal duplication.5
Git Hygiene15
    Commit FrequencyFrequent, meaningful commits throughout development with clear descriptive messages15
Total Points100