-
Couldn't load subscription status.
- Fork 38.8k
Description
This is basically a request similar to #30935.
The solution provided by #31413 is unfortunately not ideal as it forces callers of HTTP interface client to deal with classes that are a part of Spring's REST clients infrastructure (UriBuilderFactory), which goes against the appeal of HTTP interface clients which IMO exactly is to hide the entire infrastructure behind the interface so that clients can be injected in parts of the codebase that deal with the business logic.
To give more context, I'm integrating with a platform that has its services co-located in multiple datacenters across the world. The APIs in all datacenters are the same, it is only hostname that changes, for example:
cn.example.comfor China datacentereu.example.comfor EU datacenterin.example.comfor India datacenterus.example.comfor US datacenter- ...
In this scenario I have to specify UriBuilderFactory argument to each and every HTTP interface client. With several APIs each exposing multiple operations, we're talking about tens of methods that have to deal with UriBuilderFactory.
A more friendly approach would be to have the ability to provide an HTTP interface client method argument that Spring could then use to resolve base URL behind the scenes. This argument could in some cases be used only for this purpose, in some it would also have other purposes (for example, it could be a @PathVariable), but the point is that it would be something that belongs to the domain of the given API and therefore wouldn't pollute the callers with REST clients infrastructure concerns. In my specific scenario, this would be user id that has prefix that matches part of the hostname to be resolved (cn/eu/in/us/...).