Spring Boot版本化API请求模型重复问题的优化方案咨询

针对你遇到的API版本化中请求/响应模型重复的问题，以下是几个实用的优化方案，同时也会分析现有方案的合理性：

方案1：继承复用+注解覆盖 #

通过定义通用父类封装所有相同字段，子类仅重写vin字段并添加对应版本的校验规则，避免重复代码。

示例代码（请求模型）： #

// 通用父类，封装除vin外的所有字段
public class BaseCarRequest {
    private String model;
    private Integer year;
    // 其他通用字段的getter/setter
}

// V1版本请求模型
public class V1CarRequest extends BaseCarRequest {
    @Size(min = 10, max = 10, message = "V1版本vin长度必须为10位")
    private String vin;
    // vin的getter/setter
}

// V2版本请求模型
public class V2CarRequest extends BaseCarRequest {
    @Size(min = 11, max = 11, message = "V2版本vin长度必须为11位")
    private String vin;
    // vin的getter/setter
}

响应模型CarResponse和CarResponse2可以用同样的方式处理，父类封装通用字段，子类仅重写vin字段。

注意：部分校验框架默认支持子类重写字段的注解覆盖，比如Spring Validation。

方案2：自定义动态校验注解 #

如果不想维护多个POJO，可以定义一个通用的请求/响应模型，通过自定义校验注解根据API版本动态判断vin的长度规则。

示例代码： #

首先定义自定义校验注解：

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = VinSizeByVersionValidator.class)
public @interface VinSizeByVersion {
    String message() default "vin长度不符合当前API版本要求";
    Class<?>[] groups() default {};
    Class<? extends Payload>[] payload() default {};
}

然后实现校验器，通过请求路径获取当前API版本，动态校验：

public class VinSizeByVersionValidator implements ConstraintValidator<VinSizeByVersion, String> {
    @Autowired
    private HttpServletRequest request;

    @Override
    public boolean isValid(String vin, ConstraintValidatorContext context) {
        String requestPath = request.getRequestURI();
        if (requestPath.startsWith("/v1/")) {
            return vin != null && vin.length() == 10;
        } else if (requestPath.startsWith("/v2/")) {
            return vin != null && vin.length() == 11;
        }
        return false;
    }
}

最后在通用模型中使用该注解：

public class CarRequest {
    private String model;
    private Integer year;
    @VinSizeByVersion
    private String vin;
    // getter/setter
}

这种方案适合版本差异极小的场景，减少POJO数量，但需要额外维护自定义校验逻辑。

方案3：核心模型+DTO映射 #

定义一个无版本限制的核心业务模型，然后针对不同版本定义轻量的DTO（仅包含版本专属的校验规则），通过MapStruct等映射工具自动完成核心模型与DTO之间的转换。

示例代码： #

// 核心业务模型，无版本相关校验
public class CoreCar {
    private String model;
    private Integer year;
    private String vin;
    // getter/setter
}

// V1版本请求DTO
public class V1CarRequest {
    private String model;
    private Integer year;
    @Size(min = 10, max = 10)
    private String vin;
    // getter/setter
}

// MapStruct映射接口
@Mapper
public interface CarMapper {
    CarMapper INSTANCE = Mappers.getMapper(CarMapper.class);
    CoreCar toCoreCar(V1CarRequest request);
    CoreCar toCoreCar(V2CarRequest request);
    V1CarResponse toV1Response(CoreCar coreCar);
    V2CarResponse toV2Response(CoreCar coreCar);
}

这种方案将业务逻辑与API版本契约解耦，核心逻辑复用，仅在DTO层维护版本差异，适合后续版本可能增加更多差异的场景。

现有方案的合理性分析 #

如果当前仅vin字段存在校验差异，现有双POJO方案虽然存在代码重复，但胜在契约清晰——每个版本的请求/响应模型独立，阅读和维护成本低，不会因为动态逻辑引入隐藏问题。但如果后续版本差异增多（比如新增字段、修改其他字段规则），重复代码会快速膨胀，此时建议采用上述优化方案。

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