Dropwizard Validation

Introduction

Dropwizard compiles dependable, mature libraries from the Java ecosystem into a straightforward, lightweight package that frees you to concentrate on getting things done.

With Dropwizard, you and your team can provide a production-quality web service as soon as possible, thanks to its out-of-the-box support for advanced configuration, application metrics, logging, operational tools, and much more.

Validation

When constraints are broken, endpoints can send useful error messages thanks to various validation tools pre-installed in Dropwizard. Because Hibernate Validator is included with Dropwizard, anything that can be done with Hibernate Validator can also be done with Dropwizard.

Thanks to various validation tools preloaded with Dropwizard, endpoints may give helpful error messages when constraints are violated. Everything that can be done with Hibernate Validator can also be done with Dropwizard because it ships with it.

Resource endpoints allow for the validation of almost anything. For illustration, the following endpoint forbids the use of a name query parameter null or empty.

public class Name{
    @NotEmpty(message = "Name may not be empty")
    private String name;
}

If a client sends a name query param that is empty or nonexistent, Dropwizard will respond with the error: query param name may not be empty.

public class Student {   
    @NotEmpty
    private final String gender;   
    @JsonCreator
    public Student(@JsonProperty("gender") String gender) {       
        this.gender = gender;   
    }   
    @JsonProperty("gender")    
    public String getGender() {       
        Return gender;   
    }   
}

We can add the @Valid annotation to our resource class to verify its legitimacy. Utilize @NotNull and @Valid.

If the field is not there, Dropwizard will respond with a 422 Unprocessable Entity response describing the validation mistakes: the name might not be blank.

When a type can be immediately validated, such as an int, String, or int Integer, you don't require @Valid.

The instances of a class must be annotated @Valid if any of its fields require validation.

Dropwizard will prevent null input because our entity is also marked with @NotNull and will respond with a warning that the body cannot be null to prevent this.

It is also possible to confine parameter types like IntParam and NonEmptyStringParam.

@NotNull(payload = Unwrapping.Unwrap.class)
@Max(value = 6, payload = Unwrapping.Unwrap.class) IntParam num)

 In addition to making sure the query parameter is present, one may anticipate Dropwizard to give the client a list of viable possibilities. When an incorrect parameter is supplied, the choice for the query parameter must be one of the Options. 

First, an attempt is made on the name() field of the enum that the query argument is deserialized into, and then function toString() { [native code] } is tried (). Whitespace is removed from the query parameter, and dashes and dots are normalized to underscores for the case-insensitive comparisons. This reasoning is also applied when deserializing request bodies with enums.

It seems sensible to want to assure clients that the server's answer will be accurate.

For instance, you could wish to state that no response will ever be null and that a Person created by an endpoint is a legitimate human being.

@POST

@NotNull

@Valid

An empty object annotated with @NotNull may cause the server to respond, perhaps not returning null, similar to an empty request body. The error message "query param name may not be empty" will be included in Dropwizard's response if a client delivers a name query param that is either empty or nonexistent. In addition, restrictions on annotations like HeaderParam, CookieParam, FormParam, and others, with violations resulting in descriptive errors and 400 status codes.

Adding validation annotations to each field that you wish to apply constraints is the first step in configuring validation on the model side.

In the name field of our Event class, we add @Size and @NotBlank, and in the description field, we only put @Size.

@NotBlank(message = "Name is required.")
@Size(min = 8, max = 70, message = "Name must be between 8 and 70 characters")
private String name;

@Size(max = 350, message = "Description too long!")
private String description;

The @Size parameter's min and max arguments define the minimum and maximum character counts. No minimum or maximum is applied to the field if one of these is omitted. We can make this parameter optional for our description field by leaving off min.

Each of our annotations also accepts a message argument, which gives the user a clear message to see if the specific validation rule fails. In a subsequent section, we'll learn how to display them in a view.

The next step is to add a new field to each event's data to record a contact email. Indirectly applying each of the requirements an email must meet makes it very challenging to validate email addresses.