A useful first Java backend project should show what happens when a request is wrong, as well as when it is correct. Build a tiny task-title API with Spring Boot: accept a JSON request, validate the title and return a response you can explain. You can practise this before adding a database or a frontend.
This is an educational project outline with small code examples, not a production-ready task manager. Use fictional task titles. The examples have been checked against the official references below; the expected responses are a test plan for you to run, not a record of an executed build.
1. Set up a small project
At Spring Initializr, generate a Java project with Spring Web and Validation. Choose a supported stable Spring Boot release and a compatible JDK, following the generated project requirements. Keep the generated application class in com.example.taskdemo and place the two files below in the same package. Use the generated Maven or Gradle wrapper to build and run it.
You should already be comfortable with Java classes, method parameters, JSON objects and the difference between an HTTP request and response. If those are new, practise them before adding persistence or authentication.
2. Define the request rules
For this exercise, a title must contain a non-whitespace character and have no more than 80 characters. These are project rules, not rules every application must use. Create CreateTaskRequest.java:
package com.example.taskdemo;
import jakarta.validation.constraints.NotBlank;
import jakarta.validation.constraints.Size;
public record CreateTaskRequest(
@NotBlank(message = "Enter a task title")
@Size(max = 80, message = "Use 80 characters or fewer")
String title
) {}
@NotBlank covers missing, empty and whitespace-only titles. @Size provides the upper length limit. Jakarta’s NotBlank reference explains the blank-value rule. Decide separately whether your application should normalise whitespace; a validation annotation does not automatically clean the input.
3. Apply validation at the JSON boundary
Create TaskController.java:
package com.example.taskdemo;
import jakarta.validation.Valid;
import java.util.Map;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
@RequestMapping("/tasks")
public class TaskController {
@PostMapping
public Map<String, String> checkTask(
@Valid @RequestBody CreateTaskRequest request) {
return Map.of("title", request.title().trim());
}
}
The controller returns the accepted title with leading and trailing whitespace removed. It does not save a task or create a database record. Returning an object here lets Spring’s message conversion produce a JSON response in a normal Spring Web application.
For this simple signature, @Valid asks Spring MVC to validate the deserialised request object. Invalid fields normally lead to HTTP 400 before the method body runs. See Spring’s official RequestBody documentation. A broken JSON document is a different problem: parsing can fail before field validation starts.
4. Run a small, repeatable test matrix
Send each JSON object to POST /tasks with Content-Type: application/json, using your IDE’s HTTP client or another API client. The expectations below assume this minimal project, without extra security filters or custom exception handling. Start locally; do not send practice requests to an unrelated public website.
| Request | Expected result | What it checks |
|---|---|---|
{"title":"Read about validation"} |
HTTP 200 with the accepted title | A valid request reaches the method |
{"title":""} |
HTTP 400 | An empty title is rejected |
{"title":" "} |
HTTP 400 | Whitespace alone is rejected |
{} or {"title":null} |
HTTP 400 | A missing or null title is rejected |
| A title made of 80 letters, then 81 letters | 200, then 400 | The length boundary is tested |
Record your actual status codes and response bodies. Do not assume a particular error-message JSON shape: it can depend on your Spring Boot version and error-handling configuration. If you receive 401 or 403, inspect security configuration before blaming validation. Do not remove an application’s security protections just to match this exercise.
5. Turn the exercise into portfolio evidence
In your README, include the exact Java and Spring Boot versions, build command, request examples, actual test results and a short explanation of each annotation. Add one screenshot of your own API-client results, keeping personal data and secrets out of the image. Then explain one limitation: this example does not persist data, check duplicate tasks or decide which user may change a task.
A sensible next step is an explicit error-response format, followed by automated tests and persistence. Keep syntax validation, business rules and access control separate. For example, checking whether a task already exists requires application logic; checking whether someone may edit it requires authorisation.
Frequently asked questions
Is browser-side validation enough?
No. A client can send requests directly to the API. Keep useful frontend checks for usability and validate again at the backend boundary.
Does a validation annotation guarantee that the API is secure?
No. Input checks do not replace authentication, authorisation, safe data access or other controls required by the application.
What should a beginner show in an interview?
Explain one valid request, one invalid request, the expected status code and the test you actually ran. Describe your own changes and the limits of the project rather than presenting a copied tutorial as client work.
Spring’s form-input validation guide provides a separate form-based exercise. This article uses JSON requests; HTML form binding follows a different path.
For guided learning, explore ScholarLogic’s Java Full Stack course in Bangalore, taught at BTM Layout or online. Ask the team about the current syllabus, project feedback and demo availability. Confirm fees, batch dates and support terms before enrolling; completing a practice project does not guarantee employment.