What this prompt does
This prompt has the model act as a senior Java engineer and return complete, compilable Spring Boot 3 code with the full project structure, not isolated snippets. It assembles the pieces a real REST API needs together — validated DTOs, a global exception handler, JPA persistence with migrations, and integration tests against a real database — so the build is green from the first commit rather than after days of gluing fragments.
The [resource] variable names the API resource and shapes the DTOs, entity, and CRUD endpoints. [java_version] sets the language level (records, pattern matching, and so on), [database] drives the JPA dialect and Flyway migrations, and [base_path] is where the controller exposes its routes. The result uses Java records for request/response DTOs with Bean Validation, an exception handler returning RFC 7807 problem details, and Testcontainers tests that hit the actual [database] rather than an in-memory substitute, so dialect-specific behavior is exercised.
When to use it
- Standing up a new Spring Boot 3 REST resource with validation and migrations done correctly.
- Wanting RFC 7807 problem-details error responses instead of ad-hoc error JSON.
- Generating an OpenAPI spec and Swagger UI alongside the endpoints via springdoc.
- Adding Testcontainers integration tests that exercise the real database, not H2.
- Establishing a clean, conventional JVM backend for a client on the Spring stack.
- Producing CRUD with pagination and sorting under a fixed base path without hand-wiring it.
Example output
You get the package tree first, then each file in its own fenced block with the path as a header. That includes Java record DTOs with Bean Validation, the global exception handler, the JPA entity and repository, Flyway migrations creating the schema, a CRUD controller under [base_path] with pagination and sorting, springdoc OpenAPI config, and Testcontainers tests covering the happy path plus validation failures. It's a coherent, compilable slice you extend, not scattered fragments, and the structure mirrors a conventional Spring Boot layout your team will recognise.
Pro tips
- Pin your Flyway baseline early — retrofitting migrations onto an existing schema is the painful part, so start clean if you can.
- Set
[database]to your real target so the dialect, types, and Testcontainers image all match production. - Name
[resource]with its real fields and relationships so the DTOs, entity, and validation reflect your actual model. - Choose
[java_version]to match your build; records and newer syntax only work if the compiler level supports them. - Use
[base_path]consistently with your API versioning scheme so routes line up with the rest of the service. - Keep the RFC 7807 handler as the single error path so every endpoint returns consistent problem-details responses.
