AI-powered Student Management System
Production-grade full-stack platform with role-based portals, real-time analytics, and a Random Forest model that predicts academic risk with 96% accuracy.
REST API Reference
The system exposes JSON endpoints for programmatic access and future frontend integration (React SPA, mobile apps, partner integrations). The JSP-rendering servlets and the JSON-returning servlets share the same DAO layer: no logic duplication, no risk of the two views diverging.
All endpoints require an authenticated session (cookie-based) and respect the same role-based access control as the JSP views. A student requesting /api/students gets a 403; staff get the full roster.
Endpoints
| Endpoint | Method | Description | Example Response |
|---|---|---|---|
/api/students | GET | All students with calculated GPAs | [{"id":3, "firstName":"Alice", "gpa":3.89}] |
/api/courses | GET | All courses | [{"courseCode":"CS602", "credits":3}] |
/api/enrollments | GET | All enrollments with joined student + course data | [{"studentName":"Alice Johnson", "grade":"A"}] |
/api/stats | GET | Dashboard statistics | {"totalStudents":13, "avgGpa":3.04} |
Design notes
One JSON shape per endpoint. No ?format=json query params, no content negotiation by Accept header, no overloaded endpoints that return HTML for browsers and JSON for API clients. The /api/* URLs are explicitly the API. Clean separation.
GPA is computed server-side, not stored. The students table has a gpa column for legacy reasons, but /api/students computes the current GPA from the enrollments JOIN on the fly. This guarantees consistency: if you update a grade, the next API call reflects it, no cache invalidation needed.
Enrollments include joined data. Rather than returning enrollment rows with just IDs and forcing clients to make N+2 follow-up calls for student and course names, /api/enrollments includes the joined studentName and courseName. One round-trip, full context.
Stats are aggregated server-side. The dashboard could compute totalStudents and avgGpa from /api/students client-side, but that requires shipping the full roster to a browser that only needs the summary. The /api/stats endpoint runs the aggregations in MySQL where they belong.
What's not exposed
No POST/PUT/DELETE endpoints in the current build. All mutations go through the JSP-rendering servlets, which use traditional form submissions with CSRF protection via the servlet container. Adding write endpoints is straightforward: the DAO methods already support it, but I haven't built them yet because there's no client that needs them.
No /api/auth/login endpoint. Authentication still goes through the standard /login POST with session cookies. A token-based auth flow (JWT, OAuth) would be the right pattern for an API consumed by mobile apps or external partners, and that's on the roadmap.
No pagination on /api/students or /api/enrollments. At current scale (13 students, 26 enrollments), it's not needed. For a production deployment with thousands of students, cursor-based pagination would be the right pattern.