-
Notifications
You must be signed in to change notification settings - Fork 38k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce RestClient #29552
Comments
After team discussion, it has been decided that the 6.1 timeline will be too early for us to fully implement a Loom-ready WebClient. There are simply too may unknowns: underlying ClientHttpRequestFactory implementations that yet have to reveal their plans for Loom support, it is unclear what structured concurrency will look like in a Loom environment, and so on. Implementing a new, Loom-ready WebClient in 6.1 could mean that we end up with something that is not ready for the future. Therefore, we have decided to do experimental work on this issue in parallel to the 6.1 release, but not make the issue part of this release. Note that we are still considering other areas for Loom compatibility for 6.1, including the existing (reactive) WebClient and RestTemplate. |
This is amazing, but please, keep the package server(arch)-agnostic this time (reactive/servlet) |
Spring 6.1 M2 will see the introduction of |
Out of curiosity, why use "Rest" as part of the name if it can be used for anything HTTP-related, such as GraphQL? I admit it's tough to come up with a good, descriptive name that also rolls easily off the tongue, though, especially since "HttpClient" is already taken. |
The prefix In retrospect, I would not have have given |
with RestClient in place, will RestTemplate get deprecated in 6.1 timeframe? |
@anbusampath Please read that page you linked to again, as it does not contain the text you quoted.
|
sorry my bad, I was reading old doc - https://docs.spring.io/spring-framework/docs/5.2.1.RELEASE/javadoc-api/index.html?org/springframework/web/client/RestTemplate.html and attached latest doc link.
Thanks for the clarification. |
Will this new |
watch this issue - #30117 |
Thanks for making this happen @poutsma (and the team). With I'm curious whether the team considered making the new client a part of separate module, rather then having it again (as with Regarding naming, did you consider going with |
This was not considered.
A HttpClient based the
I am not sure what gave you that feeling, because the |
This commit introduces an overloaded version of RestClient::exchange, adding a boolean parameter that indicates whether the connection is closed after the exchange function is executed. See gh-29552
I understand that this would be a significant undertaking, and one that wouldn't be fully possible without breaking changes and therefore a new major release. However, IMO With the introduction of a modern HTTP client to the JDK itself, it's even more difficult to swallow the extra components you need to put to your classpath in order to use the new
The same concerns from my end apply to Anyhow, this is (to me) a less important concern to how things are laid out across Spring modules. |
Naming is hard, and it's not always about picking the most logical name. The choice has to be made in a specific context, and in the given context the chosen name is good. The The Spring Framework has many clients, two HTTP clients, two WebSocket clients, SockJsClient, TCP client, STOMP client, RSocket client, DatabaseClient, and not even counting the various templates for JDBC, JMS. Across Spring projects there are many more. There would be many new jars down this road, tempting as it might look for one case, I'm not sure the overall end result is a better place. Many of those clients support different underlying libraries. It's not clear if you actually want this split even further, e.g. one HTTP client jar for the JDK client, another for Jetty, another for Apache HTTP Components, and so on, but clearly that would be even more jars, or otherwise you still have a jar with some optional dependencies at least. Our view is that we try to structure modules but any optional dependencies within should not have impact you in any way as long as the classes are not used. |
My preference would be to have a single Spring module that carries all the HTTP-client related code, with supported underlying libraries being expressed through optional dependencies. On projects I work on I'm really picky about what I put on the classpath and really like to avoid having anything that's not really necessary. So I'm never thrilled to see server- and client-side components mixed together. My own preferences aside, there are numerous benefits of keeping the two apart:
|
Does Is the alternative using the EDIT: issue tracking this #31275 |
@wimdetroyer, In the mean time, you can bridge @Test
void exampleTest(@Autowired TestRestTemplate restTemplate) {
RestClient restClient = RestClient.create(restTemplate.getRestTemplate());
// ...
} |
Does RestClient have a retry mechanism support? How we can configure the client to retry requests when specific exception is thrown? |
Use spring retry |
|
In Spring Framework 5.0, we introduced the
WebClient
: a new, reactive HTTP client. Compared toRestTemplate
, the previous generation,WebClient
improved HTTP access on two fronts:With the advent of Project Loom, asynchrony can be obtained through standard, synchronous APIs. We should therefore introduce a version of
WebClient
that offers the same improved APIs as the current reactive version, but exposes them in a synchronous manner.The text was updated successfully, but these errors were encountered: