Skip to content

Implement UriTemplateRequestEntity::getUrl #27790

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

Closed
EricC-59 opened this issue Dec 9, 2021 · 2 comments
Closed

Implement UriTemplateRequestEntity::getUrl #27790

EricC-59 opened this issue Dec 9, 2021 · 2 comments
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement

Comments

@EricC-59
Copy link

EricC-59 commented Dec 9, 2021

Affects: Spring Framework 5.3.13


When creating a RequestEntity with a template and a parameter list, the resulting URL is not available in the created RequestEntity object.

For instance, the following code returns a RequestEntity with a null URL attribute:

RequestEntity<String> r = RequestEntity.post("http://www.example.com/{path}", "myPath").body("");

r.getUrl() throws an UnsupportedOperationException

When looking at the code in RequestEntity.body(String), I see that the returned object is an UriTemplateRequestEntity extending RequestEntity, but this object seems to always have a null URL according to its constructor. Only the uriTemplate, uriVarsArray and uriVarsMap attributes are set. But these attributes are not part of RequestEntity.

So, the URL information is lost in the RequestEntity and to retrieve it, the resulting object must be cast to an UriTemplateRequestEntity, which breaks the encapsulation principle.

Shouldn't the getUrl() method be overridden in UriTemplateRequestEntity?

A similar issue exists here, but it does not seem to fix the root cause.

I also asked a question about that in Stackoverflow but I guess I only will get workarounds.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Dec 9, 2021
@poutsma
Copy link
Contributor

poutsma commented Dec 13, 2021

There is no guarantee that the variables and template contained in the RequestEntity itself are sufficient to be resolved into a URI. The template might make use of a default URI or default variables, which can only be resolved via a UriBuilderFactory that is typically configured through the RestTemplate. So even if we would override UriTemplateRequestEntity::getUrl, many users would still face exceptions.

Then there is the possibility of users configuring a different encoding mode, which means that the URL returned by UriTemplateRequestEntity::getUrl would not be identical to the one actually resolved by the RestTemplate. Users would be confused by this, and rightfully so.

So instead of implementing UriTemplateRequestEntity::getUrl in a way that still would not work for everyone, and might return invalid results for others, we decided to be clear and not implement the method at all.

Hope that clears things up.

@poutsma poutsma closed this as completed Dec 13, 2021
@poutsma poutsma added in: web Issues in web modules (web, webmvc, webflux, websocket) and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Dec 13, 2021
@poutsma poutsma changed the title URL information is lost in a RequestEntity when constructed with RequestEntity.get(String, Object...) Implement UriTemplateRequestEntity::getUrl Dec 13, 2021
@poutsma poutsma added status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement labels Dec 13, 2021
@mikelhamer
Copy link

There is no guarantee that the variables and template contained in the RequestEntity itself are sufficient to be resolved into a URI.

So then what should I use if I want to pass around RequestEntity objects and then later retrieve their URL?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants