support @HttpExchange based interfaces

https://docs.spring.io/spring-framework/reference/integration/rest-clients.html

generate interfaces with @HttpExchange and friends so it can be used on the client side.

I was just coming to request this. :)

Requires Spring 6.1+, and became easier in Spring 7.
https://www.danvega.dev/blog/http-interfaces-spring-boot-4

The interface is very similar to the API one for controllers. The only gotcha I thought of was that you'd probably want it to have its own mapping file, not reusing the one for controllers.

Since you are using reactive, I suppose this covers RestClient and WebClient.

Just started on this a little bit... I haven't used it yet, so no idea where the issues will be. Still thinking it is just a matter of writing different annotations. ;-) What makes you think it will need its own mapping?

I've used this in a project with this generator. Mostly a copy/paste of the generated API and yes, replacing the interfaces, plus removing bean validator annotations.

On the mapping, just because the overrides where you ignore the generated DTO in favor of an internal domain object. You'd likely not want to distribute those domain objects with your SDK, instead having clients use the generated objects. You might want a different base package also, but otherwise it looks like the settings would align.

The openapi spec file will probably be different for server and client generation. Em sex., 20 de mar. de 2026, 13:07, Ted Bergeron ***@***.***> escreveu:

…

*tedberg* left a comment (openapi-processor/openapi-processor-spring#439) <#439 (comment)> I've used this in a project with this generator. Mostly a copy/paste of the generated API and yes, replacing the interfaces, plus removing bean validator annotations. On the mapping, just because the overrides where you ignore the generated DTO in favor of an internal domain object. You'd likely not want to distribute those domain objects with your SDK, instead having clients use the generated objects. You might want a different base package also, but otherwise it looks like the settings would align. — Reply to this email directly, view it on GitHub <#439?email_source=notifications&email_token=ACJJTCWR5WAQB3DFFAAQ5L34RVUCLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMBZHEZDQNJSGA42M4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4099285209>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJJTCVKYIJ4JXOVQHSURC34RVUCLAVCNFSM6AAAAACWTBVC4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAOJZGI4DKMRQHE> . You are receiving this because you are subscribed to this thread.Message ID: <openapi-processor/openapi-processor-spring/issues/439/4099285209@ github.com>

I see, I didn't think that far yet. It is then probably unlikely that one would use the same interface for server- and client-side code. But use server/client specific mappings to best match the need of server/client.

valuable feedback :-)

The openapi spec file will probably be different for server and client
generation.

That should not be the case. The point of Contract First development is to design a single contract that all parties will honor. Whether OpenAPI or gRPC, all clients and servers use the same contract document. We already use
openapi-ts to generate TS clients and openapi-processor to generate the server. No adjustments are needed.

The mapping.yaml is not part of the contract, its an implementation detail.

Sure, the same spec would be shared by both server and client, but that is not the point of the discussion. One server system would expose one api to others, but could be a client of another system and that spec would be in a different file, because its a different contract. A -> B -> C B exposes a contract to A C exposes another contract to C So, system B will need to handle one spec as a server, and another as a client.

…

On Mon, Mar 23, 2026 at 9:40 PM Ted Bergeron ***@***.***> wrote: *tedberg* left a comment (openapi-processor/openapi-processor-spring#439) <#439 (comment)> The openapi spec file will probably be different for server and client generation. That should not be the case. The point of Contract First development is to design a single contract that all parties will honor. Whether OpenAPI or gRPC, all clients and servers use the same contract document. We already use openapi-ts <https://github.com/hey-api/openapi-ts> to generate TS clients and openapi-processor to generate the server. No adjustments are needed. The mapping.yaml is not part of the contract, its an implementation detail. — Reply to this email directly, view it on GitHub <#439?email_source=notifications&email_token=ACJJTCQTISUPAKTDDT3FLPT4SHKORA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJRGQ3DCOJWGE3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4114619616>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJJTCUYHNMWORCPVX267DD4SHKORAVCNFSM6AAAAACWTBVC4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMJUGYYTSNRRGY> . You are receiving this because you commented.Message ID: ***@***.*** com>

support spring exchange annotations (#439)

fix missing setup (#439)

fix/improve annotations (#439)

clean up (#439)

add documentation (#439)

move exchange/mapping annotation configuration to mapping file with s…

add integration test (#439)

updated documentation (#439)