Spring Boot动态接收不同类型RequestBody的实现方案咨询

当然可以！针对你这种同一个API URL需要兼容不同请求体结构的场景，工厂模式是非常合适的解决方案，另外还有几种贴合Spring特性的备选方案，我给你详细拆解一下：

方案一：工厂模式 + 统一请求体接收 #

因为你的SomeClass1和SomeClass2没有任何共性，直接用父类或泛型不太现实，所以我们可以先把请求体统一接收为Jackson的JsonNode，然后通过工厂类根据type路径参数选择对应的处理器，由处理器负责解析请求体并执行业务逻辑。

1. 定义通用处理器接口 #

先搞一个通用的处理器接口，每个请求类型对应一个实现类：

public interface RequestProcessor {
    ResponseEntity<?> process(JsonNode requestBody);
}

2. 实现具体类型的处理器 #

为SomeClass1和SomeClass2分别编写处理器，用Spring的@Component注解指定bean名称，刚好对应路径里的type值：

@Component("type1") // bean名称和path中的type值对应
public class Type1Processor implements RequestProcessor {
    private final ObjectMapper objectMapper;

    // 注入Spring自动配置的ObjectMapper
    public Type1Processor(ObjectMapper objectMapper) {
        this.objectMapper = objectMapper;
    }

    @Override
    public ResponseEntity<?> process(JsonNode requestBody) {
        // 把JsonNode转成具体的SomeClass1对象
        SomeClass1 req = objectMapper.convertValue(requestBody, SomeClass1.class);
        // 这里写type1对应的业务逻辑，比如调用服务、返回结果
        return ResponseEntity.ok(String.format("处理Type1请求：%s", req.toString()));
    }
}

@Component("type2")
public class Type2Processor implements RequestProcessor {
    private final ObjectMapper objectMapper;

    public Type2Processor(ObjectMapper objectMapper) {
        this.objectMapper = objectMapper;
    }

    @Override
    public ResponseEntity<?> process(JsonNode requestBody) {
        SomeClass2 req = objectMapper.convertValue(requestBody, SomeClass2.class);
        // 处理type2的业务逻辑
        return ResponseEntity.ok(String.format("处理Type2请求：%s", req.toString()));
    }
}

3. 实现处理器工厂 #

利用Spring的特性，把所有RequestProcessor类型的bean自动注入到一个Map中，这个Map就相当于我们的工厂：

@Component
public class RequestProcessorFactory {
    private final Map<String, RequestProcessor> processorMap;

    // Spring会自动将所有RequestProcessor实现类注入进来，key就是bean的名称
    public RequestProcessorFactory(Map<String, RequestProcessor> processorMap) {
        this.processorMap = processorMap;
    }

    public RequestProcessor getProcessor(String type) {
        RequestProcessor processor = processorMap.get(type);
        if (processor == null) {
            throw new IllegalArgumentException("不支持的请求类型：" + type);
        }
        return processor;
    }
}

4. 改造你的Controller #

把原来固定的@RequestBody SomeClass1改成JsonNode，然后通过工厂获取对应处理器处理请求：

@RestController
public class MyServiceController {
    private final RequestProcessorFactory processorFactory;

    // 注入工厂类
    public MyServiceController(RequestProcessorFactory processorFactory) {
        this.processorFactory = processorFactory;
    }

    @RequestMapping(value = "/myservice/{type}", method = RequestMethod.POST)
    public ResponseEntity<?> myServiceApi(@PathVariable String type, @RequestBody JsonNode requestBody) {
        RequestProcessor processor = processorFactory.getProcessor(type);
        return processor.process(requestBody);
    }
}

这个方案的好处是扩展性拉满，以后要加新的请求类型，只需要新增一个RequestProcessor的实现类，完全不用改动Controller代码，完美符合开闭原则。

方案二：利用Jackson的类型解析（需要修改原有类） #

如果允许你给SomeClass1和SomeClass2加一个父类或接口，也可以用Jackson的类型信息自动解析请求体。不过你说两个类无任何共性，这个方案可能不太适用，但可以作为备选：

1. 定义一个父类，并加上Jackson的类型注解：

@JsonTypeInfo(use = JsonTypeInfo.Id.NAME, property = "type")
@JsonSubTypes({
    @JsonSubTypes.Type(value = SomeClass1.class, name = "type1"),
    @JsonSubTypes.Type(value = SomeClass2.class, name = "type2")
})
public abstract class BaseRequest {}

2. 让SomeClass1和SomeClass2继承这个父类：

public class SomeClass1 extends BaseRequest {
    // 原有的字段和方法
}

3. Controller直接接收BaseRequest：

@RequestMapping(value = "/myservice/{type}", method = RequestMethod.POST)
public ResponseEntity<?> myServiceApi(@PathVariable String type, @RequestBody BaseRequest request) {
    if (request instanceof SomeClass1) {
        // 处理type1的业务逻辑
        return ResponseEntity.ok("处理Type1请求");
    } else if (request instanceof SomeClass2) {
        // 处理type2的业务逻辑
        return ResponseEntity.ok("处理Type2请求");
    } else {
        return ResponseEntity.badRequest().body("不支持的请求类型");
    }
}

注意这个方案要求请求体里必须包含type字段（和路径中的type对应），而且需要修改原有类的结构，所以如果你的类不能改，这个方案就pass掉。

方案三：直接在Controller里判断（适合类型少的场景） #

如果你的请求类型只有这两种，而且以后不会新增，也可以不用工厂模式，直接在Controller里处理，虽然扩展性差，但实现简单：

@RequestMapping(value = "/myservice/{type}", method = RequestMethod.POST)
public ResponseEntity<?> myServiceApi(@PathVariable String type, @RequestBody JsonNode requestBody) {
    // 最好注入Spring的ObjectMapper，不要自己new
    ObjectMapper objectMapper = new ObjectMapper();
    if ("type1".equals(type)) {
        SomeClass1 req = objectMapper.convertValue(requestBody, SomeClass1.class);
        // 处理type1逻辑
        return ResponseEntity.ok("处理Type1请求");
    } else if ("type2".equals(type)) {
        SomeClass2 req = objectMapper.convertValue(requestBody, SomeClass2.class);
        // 处理type2逻辑
        return ResponseEntity.ok("处理Type2请求");
    } else {
        return ResponseEntity.badRequest().body("无效的请求类型");
    }
}

这种方式代码量少，但以后加新类型就得改Controller，不符合开闭原则，适合小型、稳定的场景。

总结一下，工厂模式是最适合你当前场景的方案，尤其是当以后可能新增更多请求类型的时候，维护起来非常省心。

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