[REQ] Support x-spring-paginated in the java restclient library

[YLombardi]

Is your feature request related to a problem? Please describe.

This is more a question than a request, but it could lead to one.
The resttemplate library for Java generator uses Spring but doesn't support the "x-spring-paginated" extension. So, we can't use the same openapi file for both the Controller on the server side and the Api on client side.

Describe the solution you'd like

Should we add support to the "x-spring-paginated" extension in this library to generate the pageNumber, pageSize and sort parameters in the Api ?

Describe alternatives you've considered

Another solution is to have both these 3 parameters in my openapi file and the x-spring-paginated in the openapi file.
Maybe this is the recommanded solution.
With older version of the openapi-generator-maven-plugin, it caused issue where both the Pageable parameter and these 3 parameters where present in the Controller. But now it seems fixed.

Additional context

Is these the recommandation ?

With the version 7.1.0 of the generator, it didn't work fine :

With the current 7.19.0, it seems to work fine :

Expected generated code on client side :

[Picazsoo]

My understanding is that if you are the owner of the API, you should be able to manually define the page, size, sort params in the api as standard query params. Then you should be able to annotate the operations with the x-spring-paginated.

When generating for server, the generator will smartly remove the params and will replace them with the Pageable.

When generating for resttemplate, the generator will not invoke the replacement, so you should end up with a client where all the three params are still separate query params as you want them to be.

So checking the image of the API you posted above - that seems the correct way to use it and I would consider the current 7.19.0 output to be correct.

[Picazsoo]

So to reiterate:

Another solution is to have both these 3 parameters in my openapi file and the x-spring-paginated in the openapi file.
Maybe this is the recommanded solution.

Yes, I think this is the proper and common solution. Think of the x-spring-paginated primarily as a tool to help you transform the three params into the Pageable interface. It is definitely preferable to still specify the original query params to correctly define the api contract.

I am thinking about implementing a (configurable and by default disabled) functionality for the java spring codegen (server side only - no client) where you would not need to specify the x-spring-paginated on the operations and when it would detect the presence of all the three query params, it would automatically add the x-spring-paginated:true in the background and effectively process the spec as if the x-spring-paginated was present already in the spec in the first place. I imagine this might be pretty useful for cases where one is not the owner of the API spec. Of course you could still override per method by doing x-spring-paginated: false on selected operation in the spec.

I recently implemented this in the kotlin-spring generator and will test it to verify the usefulness.