I'd like to suggest introducing a new Spring Boot starter aimed at client applications, with the necessary dependencies and autoconfiguration (e.g. RestClientAutoConfiguration) for HTTP and for related slice tests. Perhaps, two starters for imperative and reactive scenarios: spring-boot-http-client-starter and spring-boot-http-client-reactive-starter, or something like that.

In the past few years, building CLI applications with Java has become more and more common, also thanks to projects like GraalVM and Spring Shell. Reducing the friction for bootstrapping a CLI project that needs HTTP interactions would greatly help increase the adoption of the Spring stack for this purpose.

Most recently, Spring AI brought new use cases for CLI applications, which would need an HTTP client infrastructure without the burden of an entire web server stack.

Besides the CLI use case, introducing such a starter would help imperative applications that need a WebClient (required by Spring AI for streaming scenarios, because RestClient doesn't support streaming) include just client dependencies instead of the entire server stack.

Whether it is possible to set the spring.main.web-application-type=none property for disabling the web server part of the autoconfigured stack, the developer experience could be improved. Also, including several additional server dependencies which are not used is not ideal, especially from a maintenance and supply chain management point of view.

It would be great to be able to bootstrap a client-only application from Spring Initializr. I'm available to help with the implementation, if you think this is something that makes sense for the project.

Related issues on Spring Boot:

  • https://github.com/spring-projects/spring-boot/issues/12973
  • https://github.com/spring-projects/spring-boot/issues/34198

Related issues on Spring AI:

  • https://github.com/spring-projects/spring-ai/issues/524
  • https://github.com/spring-projects/spring-ai/issues/563
  • https://github.com/spring-projects/spring-ai/issues/1066

Related issues on Spring Pet Clinic:

  • https://github.com/spring-petclinic/spring-petclinic-microservices/issues/282

Comment From: wilkinsona

Thanks for the suggestion. As things stand, we can't differentiate between a dependency on spring-webflux that's intended to provide a reactive HTTP client and a dependency on spring-webflux that's intended to provide a reactive web server. As such, this is largely a duplicate of #12973 and/or #37599. We can leave this issue open to consider providing a starter or two for HTTP client applications, but it's blocked until one or both of those issues has been tackled.

Comment From: ThomasVitale

Ok, thanks for the quick and detailed answer.

Comment From: codefromthecrypt

fyi I ran into this, and while tricky hope there's a way to do this. I want to be able to make CLI commands with spring AI and not have to add tracing code to get a root span for all its work done.

This isn't isolated to spring boot, the problem with client and server in the same stack.

For example, in python, there's also a tension about flask, as "click" (CLI commands) could co-exist with server routes. The issue plays out in observability. You totally want a root span for a one-shot CLI function (otherwise you'll have a disaster of individual traces or manual code to make one which is boilerplate even if using annotations). OTOH, if the cli command starts a server, you don't want all http requests spans be rooted with the command to start the server.

There was a glitch of this kind due to conflation and luckily fixed https://github.com/open-telemetry/opentelemetry-python-contrib/pull/3174

Hope these anecdotes help

Comment From: ThomasVitale

I tried the new spring-boot-starter-restclient and spring-boot-starter-webclient starters introduced in Spring Boot 4 and they seem to fulfil the feature request. They're also already available on the Spring Initializr. I would say I could close this issue, unless there's something more that makes sense to track here? @wilkinsona

Comment From: wilkinsona

Thanks, @ThomasVitale. I don't think there's anything more to do here, we just forgot about this issue when working on the modularization. I'll close this one.

Comment From: ThomasVitale

Thank you, @wilkinsona!