I have a case where I have a search endpoint with many possible parameters. On the server side, I have a @BeanParam keeping the method signature sane.
I would like similar functionality, to use a pojo to specify the possible params and not have to include them all in the method signature. Is there a way to do this?
@GET
Set<Extension> getByFilter(@RestQuery Map<String, String> filter);
seems close, but I would rather specify an actual pojo rather than deal with making a map.
@BeanParamis definitely works on client side.Configuring OpenapiTools to generate parameters as
@BeanParamA sample endpoint which allows a custom headper parameter
X-Custom-Headerand three query params like:filter_name,filter_age,filter_activeis documented like:By default Openapi Generator will create a method and that's signature will contain every parameter one by one.
Using the following plugin configuration will generate interfaces using one parameter object annotated by
@BeanParamNote #1 the magic is
useSingleRequestParameterconfiguration option.Note #2 there are some hidden trap in the built-in template. E.g. an unvanted Apache CXF import definition which may cause compile errors. So,
<additionalProperties>disableMultipart=true</additionalProperties>property is important to set.Now, the generated method signature will be:
and the
ApiGetRequest(sorry for that name, I didn't use operationId and/or tags in the sample)On the server side the registered client will be available.
However, Openapi Generator can generate functions with a single argument it has lack of utilization capabilities (like inheritance, reuse common parts, etc.)
Fortunately JakartaEE standard supports that, but it has to be created manually.
Creating more complex API manually
As you can see, the result type is generic and paging and sorting capabilities are utilized to a separated argument.
PagingAndSorting:
PersonFilter:
FilterResult:
Pagination:
Finally the server side code sample: