Best Practices for Parameter Validation in Backend Development

Introduction

Hello, I am Tianlu. Recently, during code reviews we encountered several bad‑smell codes due to urgent requirements, especially in parameter validation. This article summarizes the key points to watch for when reviewing parameter‑related code.

1. Avoid magic values in parameter enumeration ranges

Bad example:

@FieldScope(in={"APP","PORTAL"},message="source is not in scope")
private String source;

Good example:

@FieldScope(in={SOURCEEnum.Constant.APP,SOURCEEnum.Constant.PORTAL},message="source is not in scope")
private String source;

2. Keep parameter length consistent across interfaces

The same field channelCode was defined with a max length of 32 in interface A and 16 in interface B, while the database column is varchar(32) . Ideally, the maximum length should match the database definition.

@Length(max=32,message="Channel code is too long")
private String channelCode;

3. Use @NotBlank for non‑empty checks

@NotEmpty does not reject empty strings. Use @NotBlank to catch empty strings.

@NotEmpty(message = "source must not be empty")
private String source;

Source of @NotEmpty:

public static boolean isEmpty(CharSequence cs) {
    return cs == null || cs.length() == 0;
}

Correct usage with @NotBlank:

public static boolean isBlank(CharSequence cs) {
    int strLen = length(cs);
    if (strLen == 0) {
        return true;
    } else {
        for (int i = 0; i < strLen; ++i) {
            if (!Character.isWhitespace(cs.charAt(i))) {
                return false;
            }
        }
        return true;
    }
}

4. Keep request/response consistent with API documentation

Common bugs: adding a new response field without updating the doc, missing length constraints or enum ranges in the doc. Always synchronize code changes with the API specification.

5. Validate all request parameters

For each parameter, verify non‑null, length, and allowed value range. If a parameter can be empty but must respect length when present, handle accordingly.

@Length(max=32,message="Channel code is too long")
private String channelCode;

When a field must be non‑empty and within length:

@NotBlank(message = "channelCode cannot be empty")
@Length(max=32,message = "Channel code is too long")
private String channelCode;

6. Reduce the number of method parameters; use request objects

Bad example:

@PostMapping("/create")
public ResponseEntity
createOrder(
        @RequestParam String productId,
        @RequestParam int quantity,
        @RequestParam String shippingAddress) {
    return ResponseEntity.ok("Order created successfully");
}

Good example:

@PostMapping("/create")
public ResponseEntity
createOrder(@RequestBody OrderRequest orderRequest) {
    return ResponseEntity.ok("Order created successfully");
}

public class OrderRequest {
    private String productId;
    private int quantity;
    private String shippingAddress;
}

7. Prefer annotation‑based validation over manual checks

Bad example:

if (StringUtils.isBlank(channelCode)) {
    // throw Exception
}
if (channelCode.length() > 32) {
    // throw Exception
}

Good example:

@NotBlank(message = "channelCode cannot be empty")
@Length(max=32,message = "Channel code is too long")
private String channelCode;

8. Self‑test validation logic

Even simple validation can hide pitfalls, such as placing @Valid in the wrong location, which disables validation.

9. Perform authorization checks

When exposing query APIs, verify that the user exists and is not deactivated before returning data.

10. Document parameters with comments

Good naming reduces the need for excessive comments, but class and field comments should include author, date, and purpose. Example annotation for a field:

/**
 * Channel code, e.g., 1000, 2000
 */
@NotBlank(message = "channelCode cannot be empty")
@Length(max=32,message = "Channel code is too long")
private String channelCode;