Practical technology learning
Java Input Validation: Plan a Clear Contract for a Student Enquiry API
Input validation is a useful bridge between Core Java exercises and backend application design. Instead of starting with a large system, define one small enquiry request and describe exactly what the server will accept. This article presents a practice contract, not a production implementation or a claim about Mango Engineers' live enquiry system.
Start with a written request contract
Use a fictional learner name, a course code and a short message. Decide which fields are required, whether leading and trailing spaces are removed, which course codes are accepted and what message length your application supports. A rule that has not been decided cannot be tested consistently.
Distinguish missing values from empty strings. Also decide whether an optional field may be absent, explicitly null or an empty string. Keep the contract simple and show one accepted example in your project notes.
Separate the request from the database entity
A request object describes what a caller is allowed to submit. A database entity may contain internal fields such as an identifier, status or creation timestamp. Reusing the entity directly can make unintended fields writable.
Map accepted request fields explicitly after validation. Never assume that a field is safe to store just because it can be converted to a Java type. Apply the application's business rules at the appropriate layer.
Use validation rules deliberately
Bean Validation annotations can express common constraints in Java application frameworks. The official Spring guide demonstrates standard annotations and displaying validation errors; a REST API also needs its own consistent error-response design.
Avoid treating one annotation as a complete security solution. Validation does not replace authorisation, safe database access, request-size limits or privacy controls. Each responsibility should remain clear in your design.
Design errors for the person fixing the request
Choose a predictable error structure with a field name and a useful message. For example, an unsupported course can produce 'Choose an available course code.' Do not echo an entire submitted message into logs or expose implementation details in the response.
Keep client-visible errors separate from internal diagnostic information. If you include a request reference for troubleshooting, it should identify the event without revealing personal information. Record only the information your practice exercise actually needs.
Build a boundary-focused test table
- An accepted request produces the documented successful response.
- A required field is omitted, blank and whitespace-only in separate cases.
- A value outside the allowed set is rejected.
- An overlong message fails predictably.
- Malformed data does not create a database record.
- An error response contains no stack trace or internal SQL details.
Review the behaviour before adding more endpoints
Show another learner your contract and ask them to write a failing request without seeing your code. If the behaviour is surprising, improve the contract or the implementation. Add one new rule at a time and update the examples.
Keep the exercise focused on validation and error handling. Authentication, rate limiting and delivery integrations are separate extensions. For structured learning, discuss the current Core Java and backend progression with Mango Engineers.