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

Support dynamic URI building for the upstream service #1462

Open
dharezlak opened this issue Dec 9, 2019 · 2 comments
Open

Support dynamic URI building for the upstream service #1462

dharezlak opened this issue Dec 9, 2019 · 2 comments

Comments

@dharezlak
Copy link

dharezlak commented Dec 9, 2019

Is your feature request related to a problem? Please describe.
I would like to be able to build upstream service URI based on components of the request. For instance given a request with the path /api/{serviceName} I would like to build the upstream URI using the serviceName piece like so:

Map ports = Map.of("service1", 8080, "service2", 8081);
URI upstreamUri = "http://host:" + ports.get(serviceName) + "/";

Describe the solution you'd like
For the fluent routes (RouteLocatorBuilder) one solution might be to introduce another method e.g. uriBuilder which will have access to request details:

@Bean
public RouteLocator routes(RouteLocatorBuilder builder) {
  return builder.routes()
    .route("dynamic-route", predicate -> predicate.path(/api/**))
    .uriBuilder(request -> {
      String serviceName = "todo"; //extract service name from the reqeust's path
      return "http://host:" + ports.get(serviceName) + "/"
    })
    .build();
}

Describe alternatives you've considered
I couldn't find any alternatives. The closest I could find was the RewritePath GatewayFilter but it allows only for rewriting the path part of the URI.

@dharezlak
Copy link
Author

I just stumbled on #276 and I think undocumented AbstractChangeRequestUriGatewayFilterFactory. It looks like it solves the problem stated above.

@ryanjbaxter
Copy link
Contributor

@dharezlak yes I think that is the best solution at the moment. Unfortunately this means the URI of the route is pretty much useless which is kind of nasty. I think we need a cleaner solution to this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants