Skip to content
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

Resolve URI to baseUrl in RestClient #32679

Open
runeflobakk opened this issue Apr 19, 2024 · 1 comment
Open

Resolve URI to baseUrl in RestClient #32679

runeflobakk opened this issue Apr 19, 2024 · 1 comment
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@runeflobakk
Copy link
Contributor

runeflobakk commented Apr 19, 2024

I started using the new RestClient today, and stumbled upon a surprise in the API/behavior.

Creating a client instance can be done with e.g. RestClient.create("https://my.baseurl.com"), which makes sense; you need only once to provide the base URL of, say, an API you are a consuming.

Then, when doing requests, there are two .uri(..) overloads accepting a String and a URI. The String parameter name for .uri(String, Object...) is uri, so both these methods are named "uri", and accepts the concept of a URI as argument, though represented by different types. My expectation is that these methods behave in the same way.

The documentation for .uri(String, Object...) says explicitly "If a UriBuilderFactory was configured for the client (e.g. wth a base URI it will be used to expand the URI template". And this will indeed resolve the given uri wrt to the baseUrl of the RestClient.

The documentation for .uri(URI) though says "Specify the URI using an absolute, fully constructed URI", and invoking this with e.g. URI.create("/my/path") will disregard the baseUrl of the RestClient, and issuing the request results in an exception about missing scheme in the url.

I wondered if the requirement of supplying a fully constructed URI to .uri(URI) could be lifted, and maybe resolve it against any defined baseUrl if the given URI is not absolute?

See the below test for some context:

URI baseUrl = URI.create("https://spring.io");
URI pathOnly = URI.create("/projects");
URI fullUrl = URI.create("https://spring.io/projects");

assertFalse(pathOnly.isAbsolute());
assertTrue(fullUrl.isAbsolute());
assertEquals(fullUrl, baseUrl.resolve(pathOnly));

Given the code above, I would like this to be possible:

RestClient client = RestClient.create(baseUrl.toASCIIString()); // would also be nice with a method accepting a URI as the baseUrl.
URI resolvedRequestUrl = client.get().uri(pathOnly).exchange((request, response) -> request.getURI()); // currently throws
assertEquals(fullUrl, resolvedRequestUrl);

One motivation is that I prefer to give absolute paths to other resources in the same API in responses, not actually fully constructed URLs, and I also prefer to map these links in the responses to URIs in my objects, to gain some type safety, as an absolute path (to my understanding) is a (relative) URI (see e.g. https://stackoverflow.com/a/18505331). Mapping a response to an object, I then cannot pass links (being URIs) directly to the UriSpec.uri(URI), but must convert them to String first.

Any thought on this? Perhaps there may be caveats I have not considered?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Apr 19, 2024
@snicoll snicoll added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Apr 22, 2024
@quaff
Copy link
Contributor

quaff commented Apr 23, 2024

I agree that URI should be expanded also, if it's accepted for RestClient, then same thing should apply to RestTemplate, see #27188.

@poutsma poutsma self-assigned this Apr 24, 2024
@poutsma poutsma added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Apr 24, 2024
@poutsma poutsma added this to the 6.2.x milestone Apr 24, 2024
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) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

5 participants