Claudia Sebestin - Backend take home assignment

[Clusi]

Implementation description

This backend provides a Spring Boot REST API that implements CRUD operations for a single domain object (RepairOrder) persisted in an in-memory H2 database. The API supports:

• POST /api/repair-orders (create)
• GET /api/repair-orders/{id} and GET /api/repair-orders (read single + list)
• PUT /api/repair-orders/{id} (update)
• DELETE /api/repair-orders/{id} (delete)

Technologies used

• Spring Boot (upgraded to 4.0.3) with Spring Web, Spring Data JPA, Validation, Spring Security, Actuator, and Springdoc OpenAPI
• Java (25)
• Persistence: Hibernate/JPA + H2 (ddl-auto disabled so schema is not generated implicitly)
• Schema migrations: Flyway (versioned SQL migrations under src/main/resources/db/migration)
• Seed/test data: src/main/resources/database/data.sql

Upgrades performed

• Updated the project baseline (Spring Boot + Java) to match 2026-era dependency and framework practices.
• Introduced Flyway-managed database schema migrations.
• Added OpenAPI/Swagger documentation for the secured API.
• Added production-minded cross-cutting concerns:
  • DTOs + mapping to keep API contracts separate from the persistence model
  • Bean Validation at the API boundary
  • Global exception handling producing a consistent error payload (ApiErrorDto)
  • Security with HTTP Basic and role-based method authorization (@EnableMethodSecurity + @PreAuthorize)
  • Optimistic concurrency via @Version to prevent lost updates
  • Request boundary logging with correlation id (MDC)
  • Rate limiting on /api/repair-orders/**

Architecture principles applied

• Layered design: Resource/Controller (HTTP) -> Service (use cases/transactions) -> Repository (data access) -> JPA Entity
• Stable API contracts: request/response DTOs (instead of exposing entities)
• Consistent client experience: uniform JSON error responses for validation, not-found, conflicts, and security errors
• Security-by-default: minimal public surface area, and explicit role controls for sensitive endpoints

Postman collection (manual API testing)

A Postman collection is included to test the full /api/repair-orders flow end-to-end:

• Collection file: backend/repair-order.postman_collection.json

To run it:

1. Open Postman.
2. Import the collection JSON file "repair-order.postman_collection.json".
   3Run the request group named Scenario Runner (Admin Create -> User Checks -> Admin Delete):
   • Click Run (Collection Runner) and set iterations to 1.
   • The runner uses postman.setNextRequest(...) to execute steps in sequence.