Add support for required query parameters

[ferrazoli]

The documentation states that:

Query parameters are considered optional / nullable.

It would be useful if we could pass a boolean value to the @QueryParam annotation indicating that such query parameter is required, and that the request should fail if it's not present.

Something like @QueryParam(required = true) would be very useful.

This would prevent a lot of boilerplate code for checking that required params are present.

This:

@Post
public void doSomething(@QueryParam String foo) {
  if (foo == null) {
    throw new SomeException("Query parameter \"foo\" is required");
  }
  // do stuff
}

Becomes:

@Post
public void doSomething(@QueryParam(required = true) String foo) {
  // do stuff
}

Another example, with an explicit parameter name "my-foo".

@Post
public void doSomething(@QueryParam(value = "my-foo", required = true) String myFoo) {
  // do stuff
}

Edit: Updated the examples above because as the method parameter name matches ("foo" matches foo).

[rbygrave]

As some background, JAX-RS @QueryParam does not have a required attribute but Spring MVC @RequestParam does.

An alternative would be to use a bean parameter https://avaje.io/http/#bean-param and have validation annotations on the bean. In this way the error message can be internationalised plus all the parameters are validated rather than a fail-on-first.

"Query parameter "foo" is required"

A question is if this message should be internationalised? If it gets more involved.

PathTypeConversion.checkNull() and RequiredArgumentException

Note that currently the avaje-http-api includes a static method PathTypeConversion.checkNull() and so something like that would be an option. Ultimately the exception produced needs to be translated as a 400 - Bad Request.

If there was a RequiredParameterException and it was thrown then an exception handler could be registered do perform i8n etc as needed. Hmmm.

[ferrazoli]

Thanks for the bean parameter and PathTypeConversion.checkNull() suggestions. I'll look into these!

As for i18n, I never really cared for it when building an API. I think i18n is the responsibility of the client, who should be able to show the required message based on e.g. an error code. But that's just me.

[SentryMan]

with #550, do we still need this? You can do Optional.orElseThrow();

[SentryMan]

Closing until further details are provided