Null Request Body validation

[Christopher Currie]

With 0.8.0-rc2, given a resource

@Path("/foo")

@Consumes(MediaType.APPLICATION_JSON)

class MyResource

{

  @Path("{id}")

  public Response put(@PathParam("id") long id, @NotNull @Valid RequestBody body) { ... }

}

I"m not getting the kinds of error messages I would hope to see on requests that don't contain any entity content.

If I submit:

PUT /foo/84 HTTP/1.1

Accept: */*

Accept-Encoding: gzip, deflate

Content-Length: 0

I don't get any error at all, unless I add a null pointer check in my resource's put method. Tracing the code, the JacksonMessageBodyProvider is never asked to validate the content. I would expect Jersey to complain that the content-type doesn't match the method.

If I submit:

PUT /org/84 HTTP/1.1

Accept: */*

Accept-Encoding: gzip, deflate

Content-Length: 0

Content-Type: application/json

Then the JacksonMessageBodyProvider *is* called, but I don't get any meaningful errors:

TTP/1.1 422

Content-Length: 13

Content-Type: application/json

Date: Mon, 02 Feb 2015 19:25:01 GMT

{

    "errors": []

}

422 seems an odd choice here, as well, which is supposed to be for cases where the syntax is correct, but the content can't be understood.

Is there a straightforward way to ensure I get a 400 error for this use case?

[Jochen Schalanda]

Hi Christopher,

you could use Jersey Bean Validation (https://jersey.java.net/documentation/latest/bean-validation.html) to ensure that all javax.validation annotations in the signature of the resource method are being evaluated, rather than only @Valid or @Validated.

There’s also a PR for including Jersey Bean Validation by default (https://github.com/dropwizard/dropwizard/pull/842) but I’m still not sure if that’s a good idea or if just documenting it is enough and leaves the choice to include it to the developers.

Cheers,

Jochen

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Currie]

Thanks for this tip. I finally had a chance to test it out. Some notes:

* If you are on 0.8.0-rc2, and you care about duplicate class definition warnings (and you should) the exclusions in the PR are not enough; dropwizard-validation pulls in javax.el 3.x, and jersey-bean-validation pull in javax.el 2.x. Sadly, the Maven groupIds for the both the el-api and the glassfish implementation have moved, so version pinning via dependencyManagement techniques in your POM won't help here, you'll have to explicitly exclude both artifacts from your dependencies.

* The validator doesn't have any way of figuring out resource method parameter names, and its error messages aren't really REST specific, you get errors like "put.arg0 may not be null (was null)", rather than recognizing that arg0 was the request entity, etc.

For an internal service of technical users, that might be fine, but for a public facing API it would probably not be the best. For that, I'll probably have to implement my own validation and error messaging.

Thanks,

Christopher