[BUG][JavaSpring] Spring HTTP Interface library must support useBeanValidation

[wsalembi]

Bug Report Checklist

Description

The defaults applied in #15689 are wrong regarding to useBeanValidation. Spring declares that Http Interface annotations can also be used server-side.

https://docs.spring.io/spring-framework/reference/integration/rest-clients.html#rest-http-service-client

On the server side, an @controller class can implement the same interface to handle requests with @HttpExchange controller methods.

openapi-generator version

7.0.0

OpenAPI declaration file content or url

Generation Details

Steps to reproduce

<generator>spring</generatorName>
<library>spring-http-interface</library>
<configOptions>
   <useBeanValidation>true</useBeanValidation>
<configOptions>

This option is not respected

Related issues/PRs

Suggest a fix

• useBeanValidation is forced to false in https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/SpringCodegen.java#L387

• https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/JavaSpring/libraries/spring-http-interface/api.mustache doesn't import {{javaxPackage}}.validation.constraints.*

[Picazsoo]

Hello @wsalembi, I would not necessarily treat it as a bug per se. Bean Validation on Spring declarative HTTP clients only really makes sense as a fail-fast check for outgoing requests (method parameters and request bodies). In that limited scope it helps catch obvious programmer errors before an HTTP call is made. Beyond that, it does not add much value: it does not replace server-side validation, response validation is rarely useful, and for external APIs strict client-side constraints tend to be brittle as contracts evolve independently. In practice it should be treated as a lightweight developer guardrail, not as contract enforcement. So its absence in this context is not a big deal.

So not sure how much value the validation would bring.

To be super clear - I can imagine there being value in e.g. validating responses sent from a controller to a client (on the side of the responding server that is) - to essentially make sure that the client receives output within spec. But validating requests sent to downstream server? The server should validate again anyway.

But that's just my 2 cents.

[Picazsoo]

Once again my lack of reading comprehension strikes 🤦‍♂️

I see you are writing about the use of http declarative interface as a basis for server controller, not client. You are right that it would make some sense there.

But do you think that anyone realistically uses the interface for controller? My understanding is that such controllers have very limited use in practice. Typically you would use a http interface for both client and controller in a way that you manually create the necessary interface and DTOs, etc. and create a separate versioned .jar that you then import into both client and server microservices. Then this .jar basically becomes the ultimate contract.

But since here we use the open api spec as the ultimate contract, you can as easily generate full fledged @RestController annotated interfaces with much better control over the responses (e.g. setting location headers, etc.). So I cannot imagine the practical use for that.

Basically my understanding is

• using open api as contract? - each side generates appropriate client and controller from the spec. Http interface seems to be suboptimal choice for controller. But it can be very nice for a client one.
• using http interface as contract? - each side uses it to instantiate client and controller from spec. Generating the interface from open api seems unnecessary.

But maybe I am missing something. I don't want to discount your needs.

[wsalembi]

@Picazsoo You're right about the OpenAPI being the absolute contract. That's the only artifact that we share with API consumers.

But, as a provider, when you develop your REST API controllers, it is practical to use the same interfaces for integration tests within the same maven project. Http interface also supports ResponseEntity so there are no limitations for adding HTTP headers, tweaking status code etc.

is a configuration choice for all JavaSpring generation. The default can be false for Http Interface, but if the developer decides that he still wants to use bean validation, the generator should not block the dev in making that choice.

[Picazsoo]

Understood. Thanks for presenting your PoV and usecase. Do you think you will be able to provide the bug fix? It should not be so hard I think - I expect it will be probably limited to mustache files edits. So it is easy to test the needed modifications outside of this repo if you just copy the mustache files that need changes and then experiment by loading them via the templateDir functionality.

[Picazsoo]

Ok, I see it overrides to false in the generator (as you wrote - once again my reading comprehension bites me 🤦‍♂️ ). So some changes will be needed there as well.

[Picazsoo]

Hello @wsalembi , is this what you imagine the end result should look like?

• reactive: https://github.com/Picazsoo/openapi-generator/blob/b9cb91ec5c81277979f163051ae9585d0bad300f/samples/client/petstore/spring-http-interface-reactive-bean-validation/src/main/java/org/openapitools/api/FakeApi.java
• blocking: https://github.com/Picazsoo/openapi-generator/blob/b9cb91ec5c81277979f163051ae9585d0bad300f/samples/client/petstore/spring-http-interface-bean-validation/src/main/java/org/openapitools/api/FakeApi.java

If so, can you take a look at the PR here: #22891 ?

[Picazsoo]

ping @wsalembi !

[wsalembi]

@Picazsoo Thanks for the pull request. Yes, this is the expected behavior. Ok to merge.

[wsalembi]

@Picazsoo The PR is now ready to merge?

[Picazsoo]

I added unit tests and fixed some imports issue and moved the PR from draft to ready-to-merge. Thanks for the nudge.

[KartikeyTripathi469]

Hello, I would like to work on this issue.
Could you please assign it to me?

[Picazsoo]

It is only missing a couple of unresolved things. I will take a look at my PR tonight.

[KartikeyTripathi469]

Hello, sir, could you please assign me this issue?

#23234