RESTful API Design

Relevant source files

The following files were used as context for generating this wiki page:

• src/main/java/com/example/demo/controllers/AdminController.java
• src/main/java/com/example/demo/controllers/ProjectController.java
• src/main/java/com/example/demo/controllers/AnalyticsController.java
• src/main/java/com/example/demo/controllers/SubtaskController.java
• src/main/java/com/example/demo/config/SecurityConfig.java
• src/main/resources/static/js/api.js
• src/main/java/com/example/demo/services/TaskService.java
• src/main/java/com/example/demo/services/AttachmentService.java
• README.md

The Dashboard Task Management (DTM) system utilizes a RESTful API architecture to facilitate communication between the Spring Boot backend and the Vue.js frontend. The API is designed around resource-oriented endpoints, utilizing standard HTTP methods (GET, POST, PUT, PATCH, DELETE) and JSON for data exchange. The base URL for all API interactions is http://localhost:8080/api.

Sources: README.md:6, src/main/resources/static/js/api.js:5

API Security and Authentication

The API implements a stateless security model using JWT (JSON Web Token). Authentication is handled via a dedicated authentication chain that separates API requests from standard web page requests.

Security Configuration

The SecurityConfig class defines two distinct security filter chains. The apiChain specifically targets paths matching /api/**, disabling CSRF and setting the session creation policy to STATELESS.

The diagram shows the separation of security concerns between API endpoints and standard web routes.
Sources: src/main/java/com/example/demo/config/SecurityConfig.java:40-75

Authentication Headers

All authenticated requests must include the JWT in the Authorization header.

Header	Value	Description
Content-Type	application/json	Required for body-bearing requests
Authorization	Bearer <token>	Required for all endpoints except /api/auth/**

Sources: src/main/resources/static/js/api.js:11-15, README.md:46-48

Core Resource Endpoints

The API is divided into logical modules corresponding to the system's functional blocks: Administration, Projects, Tasks, and Analytics.

1. Administration (/api/admin)

Accessible only to users with the ADMIN role, this module manages global entities like departments and users.

Method	Endpoint	Description
GET	/api/admin/auth/me	Retrieve profile of the current authenticated user
GET	/api/admin/departments	List all departments
POST	/api/admin/users	Register a new user with specific roles
PATCH	/api/admin/users/{id}/status	Activate or block a user account

Sources: src/main/java/com/example/demo/controllers/AdminController.java:30-75

2. Project Management (/api/projects)

Projects are the top-level containers for tasks. Access is governed by roles (ADMIN, MANAGER, PM, TEAM).

Method	Endpoint	Description
GET	/api/projects	List projects visible to the current user
POST	/api/projects	Create a new project (ADMIN/MANAGER only)
DELETE	/api/projects/{id}	Remove a project (ADMIN only)

Sources: src/main/java/com/example/demo/controllers/ProjectController.java:22-50

3. Task and Subtask Management

Tasks are managed within projects, often viewed via a Kanban board.

The sequence shows the process of updating a task status, including the mandatory access validation step in the service layer.
Sources: src/main/java/com/example/demo/services/TaskService.java:180-210, src/main/resources/static/js/api.js:52-53

4. Analytics and Reporting (/api/analytics)

Provides aggregated data for management. Access is restricted to ADMIN and MANAGER roles.

Endpoint	Data Provided
/api/analytics/tasks/by-status	Distribution of tasks across Kanban columns
/api/analytics/tasks/by-priority	Task counts categorized by LOW, MEDIUM, HIGH
/api/analytics/employees/performance	Metrics: assigned, completed, and overdue tasks per user
/api/analytics/tasks/{taskId}/history	Audit log of all changes to a specific task

Sources: src/main/java/com/example/demo/controllers/AnalyticsController.java:45-90, README.md:155-175

File Handling Architecture

File management follows a two-step "Upload and Bind" process to ensure files are associated with specific tasks or comments correctly.

Attachment Workflow

1. Upload: File is uploaded to a temporary directory.
2. Bind: The temporary file is moved to a permanent directory associated with an EntityType (TASK or COMMENT) and an EntityId.

File Constraints

• Max Size: 10 MB.
• Allowed Formats: jpg, png, gif, webp, pdf, doc, docx, xls, xlsx, txt, zip, rar.
• Permissions: TEAM role can only attach files to comments; ADMIN/MANAGER/PM can attach to tasks.

Sources: src/main/java/com/example/demo/services/AttachmentService.java:45-58, README.md:120-130

Response Status Codes

The API uses standard HTTP status codes to communicate request results.

Code	Meaning	Context
200	OK	Successful GET, PUT, or POST requests
204	No Content	Successful DELETE requests
400	Bad Request	Validation failures (e.g., past due date)
401	Unauthorized	Missing or invalid JWT
403	Forbidden	Role-based access violation
404	Not Found	Resource (Task, Project, User) does not exist
500	Server Error	Unexpected internal exceptions

Sources: README.md:215-225, src/main/resources/static/js/api.js:18-28

Conclusion

The RESTful API design of the DTM project prioritizes security and role-based data integrity. By centralizing request logic in api.js and enforcing strict access control in the Spring Boot service layer (notably TaskService), the system ensures that sensitive project data is only accessible to authorized personnel while providing a responsive interface for Kanban operations and analytics.