While both the admin and commerce gateway applications are independent of each other, they follow similar configuration patterns and structures.
In application.yml
, under the property prefix spring.cloud.gateway.routes
, we define the basic route configuration with entries for each service.
Each entry contains a few basic values:
Field | Description |
---|---|
|
The ID of the route itself. |
|
The uri of the destination to route to.
This is typically configured to be the value of the |
|
The predicates that must match for this route.
This is typically configured to just have the Path Route Predicate with its argument as the value of the |
|
The filters to apply to the route.
This is typically configured to just have the Rewrite Path Filter with its argument as the value of the |
The property arguments for the basic route configurations setup in application.yml
are defined in the application-default.yml
file.
See Admin gateway configuration or Commerce gateway configuration for property argument details.
The application-uber.yml
file defines the overrides for the property arguments defined in application-default.yml
when the microservice stack is bundled and deployed as a single application.
See Admin gateway configuration or Commerce gateway configuration for property argument details.
Spring Cloud Gateway predicates allow route matching based on the specified predicate type and pattern to be applied to the HTTP request attributes.
In application-default.yml
, all of the routes are configured to map HTTP request to the correct microservice API based on the request path.
This ensures requests are correctly routed to the specified gateway route
(ex: "https://localhost:8446/api/catalog/products") is correctly mapped to the catalog
route
using the predicate mapping (ex: "/api/catalog/**") and won’t cause the gateway to throw an error.
Spring Cloud Gateway filters allow the incoming or outgoing HTTP request to be modified.
In application-default.yml
, all of the routes are configured to use the RewritePathGatewayFilterFactory
.
The first argument is the regex, and the second argument is the replacement path.
The regex implementations will match the base of the path, then an optional trailing slash ("/?"), and then capture the remainder into a named group called "segment". This should ensure that the captured segment never has a leading slash regardless of the original request path.
In the replacement, we forcefully prepend a slash to the captured segment and use the result as the final path.
This ensures requests to the root path of a route with and without a trailing slash (ex: "https://localhost:8446/api/catalog/" and "https://localhost:8446/api/catalog") both get routed to a path that has a trailing slash (ex: "https://localhost:8446/") and won’t cause the gateway to throw an error.