Skip to content

mediocreasian/RestAPI-With-Auth

Repository files navigation

Author's notes:

I use a modular folder structure to organize the codebase by feature rather than by technical layer.
This approach makes the project more scalable, maintainable, and easier to navigate as new features are added.

All requirements from the initial repository README have been fulfilled.

Additional Features:

Note: Keys in secret-keys are for testing purposes only.

How to Test this Application

1. Clone the Repo

2.Start the application with Docker Compose

docker compose up --build

3. Follow the steps in tests.md

  1. Sign up
  2. Log in
  3. Perform CRUD operations for Notes

Folder Structure:

├── Dockerfile                         // Container build instructions for the application
├── README.md                          // Project overview, setup, and usage guide
├── db-changelog                       // Liquibase changelogs for database version control
├── docker-compose.yml                 // Compose file to spin up app and dependencies (DB, etc.)
├── pom.xml                            // Maven dependencies and build configuration
├── secret-keys                        // Externalized secret keys (encryption, JWT signing)  (KEYS IN REPO ARE FOR TESTING ONLY - Exel)
├── src
│   ├── main
│   │   ├── java/com/agridence/microservice/Assignment
│   │   │   ├── configuration         // Security filters, encryption setup, application configs
│   │   │   ├── dto                   // API request and response payload classes (clean separation from entities)
│   │   │   ├── exception             // Global exception handling and custom application exceptions
│   │   │   ├── modules               // Modular structure for isolated business features
│   │   │   │   ├── notes             // Notes feature module: controller, entity, service, repository
│   │   │   │   └── users             // Users feature module: controller, entity, service, repository
│   │   │   └── utils                 // Reusable utility classes (JWT operations, encryption, password hashing)
│   │   └── resources
│   │       └── application.properties // Application-specific configuration (ports, keys, etc.)

Design Rationale: Modular Separation of Concerns

While the NOTE table has a foreign key relationship to USER in the database,
the Notes Service intentionally does not depend on the User entity or ORM mappings to retrieve user details.

This is a deliberate architectural choice to maintain strict modular boundaries between features:

  1. Each feature module (users, notes, etc.) operates independently, with minimal cross-dependencies.
  2. The Notes Service retrieves the authenticated user's ID directly from the JWT token, rather than relying on User entity lookups.
  3. This enforces clear separation of concerns:
    • The Users module handles user registration, authentication, and secure credential storage.
    • The Notes module manages note creation, retrieval, and ownership validation based on the user ID extracted from the security context.

Why I chose this:

  1. Promotes scalability and feature isolation as the codebase grows.
  2. Reduces unintended coupling between modules.
  3. Allows future add on services to evolve independently without tight ORM interdependencies.

ER Diagram

erDiagram
   USERS {
      BIGSERIAL id PK 
      VARCHAR username
      VARCHAR password 
      VARCHAR full_name 
      TIMESTAMP created_at
   }

   NOTES {
      BIGSERIAL id PK
      VARCHAR title 
      TEXT description
      BIGINT user_id FK 
      TIMESTAMP created_at 
   }

   USERS ||--o{ NOTES : "owns many"

Loading

Sequence Diagrams of scenarios

User Sign up

sequenceDiagram
    participant Client
    participant AuthService
    Client ->> AuthService: Sign Up (username, password, full name)
    AuthService -->> Client: Sign Up Success

Loading

User Log In

sequenceDiagram
    participant Client
    participant AuthService
    Client ->> AuthService: Login (username, password)
    alt Valid credentials
        AuthService -->> Client: Return JWT Access Token
    else Invalid credentials
        AuthService -->> Client: Error "invalid username/password"
    end


Loading

Add Note

sequenceDiagram
    participant Client
    participant NotesService
    Client ->> NotesService: Add Note (JWT, title, description)
    NotesService ->> NotesService: Validate JWT
    NotesService -->> Client: Note Created Success

Loading

View Notes

sequenceDiagram
    participant Client
    participant NotesService
    Client ->> NotesService: View Note Details (JWT, noteId)
    NotesService ->> NotesService: Validate JWT
    NotesService ->> NotesService: Check Note Ownership
    alt Note belongs to user
        NotesService -->> Client: Note Details (title, description)
    else Unauthorized Access
        NotesService -->> Client: Error "Access Denied"
    end

Loading

Delete Note Details

sequenceDiagram
    participant Client
    participant NotesService
    Client ->> NotesService: Delete Note (JWT, noteId)
    NotesService ->> NotesService: Validate JWT
    NotesService ->> NotesService: Check Note Ownership
    alt Note belongs to user
        NotesService -->> Client: Note Deleted
    else Unauthorized Access
        NotesService -->> Client: Error "Access Denied"
    end
Loading

About

Sample REST API with JWT Auth Validation

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published