Alternative #1

I ran into this same deprecation warning last month and ended up switching to programmatic configuration instead of just updating the YAML. It's a bit more work upfront but totally worth it.

Here's what I ended up doing:

@Configuration
public class GatewayConfig {
    
    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("example", r -> r
                .path("/example/**")
                .uri("http://example.com"))
            .route("api", r -> r
                .path("/api/**")
                .filters(f -> f
                    .addRequestHeader("X-API-Version", "v1"))
                .uri("http://api.example.com"))
            .build();
    }
}

Why I went this route:

• No more deprecation warnings (obviously)
• My IDE actually autocompletes the route definitions now
• Much easier to add conditional logic when you need it
• Type safety catches mistakes at compile time instead of runtime
• Git diffs are way cleaner than YAML changes

The YAML approach above works fine if you just want a quick fix, but if you're doing any serious gateway work, the programmatic approach is the way to go. Plus, you won't have to deal with this deprecation stuff again when the next version comes out.

Alternative #2

If you're dealing with a legacy application that has tons of routes and you can't refactor everything at once, you can use a hybrid approach. I've done this in production and it works surprisingly well.

Keep your existing YAML config but add a migration configuration:

spring:
  cloud:
    gateway:
      # Keep old config for backward compatibility
      mvc:
        routes:
          - id: legacy-route
            uri: http://legacy.example.com
            predicates:
              - Path=/legacy/**
      
      # Add new config for new routes
      server:
        webmvc:
          routes:
            - id: new-route
              uri: http://new.example.com
              predicates:
                - Path=/new/**

Then gradually migrate routes one by one. You can also use profiles to switch between old and new configs:

# application-legacy.yml
spring:
  cloud:
    gateway:
      mvc:
        routes: # old config

# application-new.yml  
spring:
  cloud:
    gateway:
      server:
        webmvc:
          routes: # new config

This approach lets you migrate incrementally without breaking existing functionality.

Alternative #3

For microservices architectures where you have multiple gateway instances, consider using external configuration with Spring Cloud Config or environment variables.

Instead of hardcoding routes in YAML, use environment-based configuration:

spring:
  cloud:
    gateway:
      server:
        webmvc:
          routes:
            - id: ${ROUTE_ID:default-route}
              uri: ${ROUTE_URI:http://default.example.com}
              predicates:
                - Path=${ROUTE_PATH:/default/**}

Or use Spring Cloud Config with a centralized configuration:

# In your config server
gateway:
  routes:
    - id: service-a
      uri: http://service-a:8080
      predicates:
        - Path=/api/service-a/**
    - id: service-b  
      uri: http://service-b:8080
      predicates:
        - Path=/api/service-b/**

This approach makes your gateway configuration more dynamic and environment-aware, which is especially useful in containerized deployments where you might have different routes for dev, staging, and production environments.