Flicktionary RESTful API - A dictionary, but only for flicks.

The Challenge

The assignment was to create the server-side component of a full-stack movie app. The API needed to:

• store movies with structured information (title, description, genre, director, image, featured flag),
• store users with secure credentials and lists of favorite movies,
• allow users to register, log in, update their data and delete their account,
• expose endpoints for querying movies, genres, directors and users,
• protect most routes with JWT authentication,
• and be accompanied by clear, navigable documentation.

Beyond fulfilling the course requirements, I wanted the API to feel like something a front-end team could realistically use: predictable routes, consistent responses and thoughtful error handling.

Objectives and Success Criteria

I translated the brief into a few concrete goals:

• Model movies and users cleanly
  Use MongoDB + Mongoose to define schemas with appropriate types and validation for movies and users.

• Implement secure authentication
  Use Passport.js with JWT and local strategies, plus bcrypt for password hashing, to secure protected routes.

• Design clear, RESTful endpoints
  Provide intuitive endpoints for movies, genres, directors and users, with sensible URL patterns and HTTP verbs.

• Support favorites and profile management
  Enable users to add/remove favorite movies and update or delete their profile, with permission checks.

• Document the API for other developers
  Use JSDoc to generate documentation that includes description, authentication rules, endpoints and error responses.

I considered the project successful if someone could read the docs, obtain a token, and build a simple client that registers a user, fetches movies and manages favorites without needing to dig through the code.

• Express app structure
  The main index.js file configures Express middleware (logging, JSON parsing, CORS, etc.), sets up routes for movies and users, and wires authentication via Passport.

• Data models (Mongoose)
  models.js defines:

  • a Movie schema with fields like Title, Description, Genre, Director, ImagePath and Featured,
  • a User schema with Username, Password, Email, Birthday and FavoriteMovies (an array of ObjectIds referencing movies).
    Mongoose handles validation and maps these schemas to MongoDB collections.

• Authentication & authorization
  auth.js and passport.js configure Passport for:

  • local strategy (username/password) to issue JWTs on login,
  • JWT strategy to protect routes.
    Tokens are passed in the Authorization: Bearer <token> header and checked for protected endpoints.

• Routing & controllers
  Routes follow a REST style:

  • /movies, /movies/:Title, /movies/genre/:genreName, /movies/director/:directorName,
  • /users, /users/:Username, /users/:Username/movies/:MovieID.
    Each route handler encapsulates the logic for querying MongoDB, applying validation and sending structured JSON responses.

• Security & middleware

  • bcrypt for password hashing and verification,
  • CORS to control cross-origin requests,
  • basic security headers (e.g. X-Content-Type-Options, X-Frame-Options, X-XSS-Protection) applied via middleware,
  • morgan for HTTP request logging,
  • dotenv for environment-based configuration (port, DB URI, JWT secret).

• Documentation
  JSDoc comments in the code are compiled into a static documentation page that describes endpoints, parameters, authentication requirements and example responses.

Phase 1 – Modeling movies and users

I began by designing the data model:

• a Movie schema with nested Genre and Director objects,
• a User schema with credentials, basic profile info and an array of favorite movie IDs.

I iterated on the schemas to strike a balance between denormalization (storing genre/director info with each movie) and simplicity for client consumption.

Key learning: In document databases like MongoDB, it’s often worth embedding small, relatively static objects (like genre or director info) to reduce the number of queries the client depends on.

Phase 2 – Building core endpoints

Once the models were in place, I implemented the core routes:

• GET /movies and GET /movies/:Title to retrieve movie data,
• GET /movies/genre/:genreName and GET /movies/director/:directorName for lookup-style queries,
• GET /users and GET /users/:Username for user data.

This phase focused on getting the basic data flows working: querying MongoDB, shaping responses, and handling not-found and error cases.

Phase 3 – Authentication and user management

Next, I implemented user-focused features:

• Registration via POST /users with validation rules:
  • minimum lengths for Username and Password,
  • strong password requirements,
  • proper email format.
• Password hashing using bcrypt before storing users.
• Login endpoint that issues a JWT on successful credential verification.
• PUT /users/:Username and DELETE /users/:Username with checks to ensure users can only modify or delete their own accounts.

Key learning: Putting validation rules and clear error messages into the API itself reduces complexity for clients and helps prevent bad data from ever reaching the database.

Phase 4 – Favorites and richer interactions

With movies and users in place, I added favorites:

• POST /users/:Username/movies/:MovieID to push a movie ID into FavoriteMovies,
• DELETE /users/:Username/movies/:MovieID to remove it.

Responses return the updated user document, which makes it easy for clients to update their local state.

Key learning: Keeping favorites as IDs rather than full embedded movie documents keeps user documents lean and avoids duplication.

Phase 5 – Security headers and documentation

Finally, I improved robustness and usability:

• Enabled and configured CORS so the API can be consumed by different clients,
• Added basic security headers to reduce common attack surfaces,
• Wrote JSDoc comments alongside the route handlers and generated an HTML documentation page with:
  • descriptions,
  • authentication requirements,
  • request/response formats,
  • example payloads and error codes.

Key learning: Documentation is a feature. Having it auto-generated from the code reduces drift between implementation and docs.

My testing strategy included:

• Endpoint-by-endpoint verification

  • Calling each route with valid data (e.g. GET /movies, POST /users, POST /users/:Username/movies/:MovieID) and confirming the response shape matches the documentation.
  • Checking that authentication-protected routes return 401/403 when called without a token or with an invalid one.

• Validation and error states

  • Trying to register users with invalid data (short usernames, weak passwords, invalid email formats) to confirm the API returns 4xx errors with clear messages.
  • Requesting non-existent movies or users to verify 404 responses.

• Permission checks

  • Attempting to update or delete a user via another user’s token to ensure the API denies the operation.
  • Verifying that favorites endpoints only allow changes to the authenticated user’s own record.

• Integration-level checks with clients

  • Connecting the React and Angular clients to the API and running through typical flows (login, browse, favorite, update profile) to confirm the API behaves as expected under real usage.

If I revisit this project, a clear next step is adding automated tests (for example, using a testing framework like Jest or Mocha with Supertest) to cover the most critical endpoints and error paths.