University

Campus Connect API

A university course project focused on the backend rules behind campus clubs and events, implemented as a documented Spring Boot REST API.

Timeline: November 2025

Technologies used

Java 17
Spring Boot
Spring Data JPA
H2
SpringDoc OpenAPI
Maven

SpringDoc exposes the API surface across users, events, clubs, registrations, authentication, notifications, and administration.

Campus Connect OpenAPI documentation with seven controller groups — SpringDoc exposes the API surface across users, events, clubs, registrations, authentication, notifications, and administration.

Event discovery accepts optional club, date, and keyword filters.

Campus Connect GET events OpenAPI contract with club, date, and keyword filters — Event discovery accepts optional club, date, and keyword filters.

The registration contract sits in front of capacity, timing, account-state, and duplicate checks.

Campus Connect registration endpoint with event ID and student request body — The registration contract sits in front of capacity, timing, account-state, and duplicate checks.

A read-only administrator endpoint aggregates the seeded prototype state.

Campus Connect administrator statistics API response showing ten clubs, thirty events, and three active students — A read-only administrator endpoint aggregates the seeded prototype state.

The backend was the project

Campus Connect began as a university course project about helping students discover clubs and events. The interface was exploratory, so this entry focuses on the part I can stand behind: the Java API and the domain rules it encodes.

The service separates student, club manager, and administrator responsibilities across controllers and service classes. Students can discover clubs and events, join clubs, and register for events. Managers can maintain their clubs and event programmes. Administrators can review the system as a whole.

Turning campus activity into explicit contracts

The API is built with Java 17 and Spring Boot 3.2.5. Spring Web exposes the REST surface, Spring Data JPA handles persistence, Jakarta Validation guards request shapes, and SpringDoc generates an inspectable OpenAPI contract.

Seven controller groups cover users, authentication, clubs, events, registrations, notifications, and administration. That separation kept the HTTP layer readable while service classes owned rules such as membership uniqueness, event capacity, registration timing, and account state.

Rules before writes

Registration is more than inserting a row. The service checks that the student and event exist, that the account is active, that the event is still open, that capacity remains, and that the student has not already registered. Club membership follows the same pattern, with database constraints acting as a final guard against duplicates.

What the prototype proves

The project demonstrates a complete backend slice: relational entities, repository queries, service-level policy, REST controllers, validation, seeded data, generated documentation, and email notification hooks. Filterable event discovery supports optional club, date, and keyword parameters, while administrator statistics summarize the current prototype state.

What I would change next

This is still a course prototype, not a production authentication system. Password handling and client-supplied actor identifiers should be replaced with Spring Security, hashed credentials, and server-derived identities. Capacity enforcement should move into a transactional database operation to prevent concurrent registrations from exceeding a limit. I would also replace the in-memory database, queue outbound email, and add controller and service tests.

The repository link is intentionally withheld. The source history contains a provider credential that should be rotated and removed from history before the code is shared.