A REST controller should reject malformed input at a clear boundary and return a status the caller can interpret. Request binding, Bean Validation and business rules solve related but different problems.

This Spring Boot interview example uses a fictional parcel preview. A positive weight is required, but no parcel is booked and no database is updated. The code uses Jakarta Validation, as used by modern Spring Boot applications.

How can the request declare a simple constraint?

package example;

import jakarta.validation.Valid;
import jakarta.validation.constraints.Positive;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RestController;

record ParcelRequest(@Positive int weightGrams) { }
record ParcelPreview(int weightGrams, String status) { }

@RestController
class ParcelController {
    @PostMapping("/parcels/preview")
    ParcelPreview preview(@Valid @RequestBody ParcelRequest request) {
        return new ParcelPreview(request.weightGrams(), "valid-input");
    }
}

The application needs its web stack and a validation provider, commonly through the appropriate Boot validation starter. With this setup, zero or a negative weight fails validation before the method body produces the preview. A positive value returns the preview object.

Is binding the same as validation?

No. Binding turns incoming JSON into the request shape. Invalid JSON or a string where an integer is required can fail during conversion. Bean Validation checks constraints on a successfully bound value. Both deserve client-facing errors, but they arise at different stages.

Be deliberate about missing fields and null. A primitive int has a zero default, so Positive rejects a missing weight in this simple record. If you need to distinguish missing from zero, use a nullable wrapper with explicit required and range constraints.

Where do business rules belong?

A valid positive weight does not prove a shipment is allowed. Destination availability, capacity and permissions require application rules and authoritative state. Put reusable rules in the service layer rather than repeating them in several controllers.

Recheck rules that depend on changing state at the write boundary. A UI check performed minutes earlier cannot guarantee the state is still valid. This preview deliberately makes no booking guarantee.

How can error responses stay consistent?

Use the application's supported controller-advice or error-handling mechanism to map relevant exceptions to safe responses. Spring's ProblemDetail support can provide a standard error representation. Customize field errors deliberately and test the actual shape for your configured version.

Do not return an exception message unchanged. It may expose implementation details. Also avoid converting every exception into 400: an unexpected server failure is not necessarily the caller's mistake.

What should a controller test cover?

  • Positive integer input produces the expected fields.
  • Zero and negative values are rejected.
  • Malformed JSON does not reach the business operation.
  • A missing required value follows the documented rule.
  • Unexpected service failures return safe errors.

Verify status, content type and meaningful body fields. If the API publishes a stable field-error contract, test it explicitly. Do not assume a default framework error body is identical across versions and configuration changes.

What makes the answer complete?

Trace the request through conversion, validation, authorization, business rules and the response. Explain which failure belongs to each stage. That is more useful than saying “add Valid” without checking whether validation is enabled or whether the constraint matches the business requirement.

References and next practice

spring.io — spring rest · developer.mozilla.org — http

spring-boot question collection · Browse interview topics · Practise a question in Interview Challenge · How to Answer Technical Interview Questions Out Loud