如何在Java版AWS Lambda中实现无效API请求的非30x重定向式重路由

核心逻辑和ASP.NET的自定义路由完全一致：所有重路由动作都在服务端内部完成，不向客户端返回跳转响应，客户端全程无感知，不需要依赖30x系列状态码，具体可以根据你的架构选两种实现方式：

方案1：前置触发层路径重写（性能最优，无需改业务代码） #

绝大多数Lambda部署场景都会在前面挂API Gateway或者ALB作为触发入口，直接在这一层做路径改写是最省事的方案：

• 若使用API Gateway触发：在API路由配置中为无效路径添加路径覆盖规则，比如匹配/api/v1/hello的请求时，直接将转发给Lambda的请求路径改写为/api/v2/hello，原请求的header、参数、body全部透传。重写动作完全在网关转发前完成，客户端拿到的就是v2接口的正常处理结果，不会收到任何跳转提示。
• 若使用ALB触发：在ALB的监听规则中配置路径重写动作，匹配旧路径规则后直接改写转发目标路径，同样是服务端内部操作，不会触发客户端跳转。

方案2：Java Lambda代码内部实现路由转发（无需修改网关配置） #

这个方案和你在ASP.NET启动类中写自定义路由映射的逻辑完全对齐，不管你用原生Lambda runtime还是Web框架适配层都能实现：

原生RequestHandler实现 #

直接在Lambda入口方法的最前置位置加路由判断逻辑，匹配到无效路径时直接调用对应有效路径的处理方法，不构造重定向响应即可，示例代码：

public class MainHandler implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {
    // 提前初始化有效路径的处理器实例，避免每次请求重复创建
    private final HelloV2Handler helloV2Handler = new HelloV2Handler();

    @Override
    public APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent request, Context context) {
        String path = request.getPath();
        // 自定义重路由规则：匹配旧路径直接透传请求到v2处理器
        if ("/api/v1/hello".equals(path)) {
            return helloV2Handler.handleRequest(request, context);
        }
        // 其余正常路由处理逻辑
        // ...
    }
}

注意：这里是直接在方法内部调用目标处理器的逻辑，不是返回带Location头的30x响应，客户端拿到的就是v2逻辑处理后的正常返回结果，完全感知不到路由转换过程。

基于Web框架的实现 #

如果你用Spring Cloud Function、Micronaut等适配Lambda的Web框架，直接用框架自带的路由拦截能力即可：

• 以Spring Cloud Function为例，注册一个拦截器在请求匹配Controller之前执行，判断到旧路径时直接改写请求的ServletPath为对应v2路径后放行，框架会自动将请求路由到v2对应的Controller方法，全程不需要构造跳转响应。

避坑提示 #

不要在处理逻辑中返回设置了301/302/307状态码、携带Location响应头的结果，这种方式才会触发客户端侧跳转，不符合需求。

内容的提问来源于stack exchange，提问作者TDao