优化APIDTO设计，降低代码重复率

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《优化API DTO设计，减少请求响应代码重复》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

RESTful API DTO设计中的挑战

在典型的RESTful API设计中，为请求和响应分别定义DTO是一种常见实践。例如，一个用户创建请求可能只需要firstName和lastName，而用户查询响应则需要包含这些信息，同时还要加上id、version、created和modified等系统生成或维护的元数据。 传统的做法可能导致如下的DTO结构：

// 基础响应DTO，包含通用元数据
public abstract class BaseResponseDTO {
    protected UUID id;
    protected Integer version;
    protected Date created;
    protected Date modified;
}

// 用户请求DTO
public class RequestUserDTO {
    private String firstName;
    private String lastName;
}

// 用户响应DTO，继承BaseResponseDTO并重复了RequestUserDTO的字段
public class ResponseUserDTO extends BaseResponseDTO {
    private String firstName;
    private String lastName;
}

显而易见，ResponseUserDTO中firstName和lastName字段的定义与RequestUserDTO存在重复。为了解决这种重复，开发者可能尝试多种方案，但往往不尽理想：

1. 多重继承（Java不支持）：设想ResponseUserDTO能够同时继承BaseResponseDTO和RequestUserDTO，但这在Java中是不允许的。

2. 组合模式：引入一个公共的UserDTO，然后在请求和响应DTO中通过组合方式引用它。

   public abstract class BaseResponseDTO {
       protected UUID id;
       protected Integer version;
       protected Date created;
       protected Date modified;
   }
   
   public class UserDTO { // 核心用户数据
       private String firstName;
       private String lastName;
   }
   
   public class RequestUserDTO {
       private UserDTO payload; // 强制客户端包装
   }
   
   public class ResponseUserDTO extends BaseResponseDTO {
       private UserDTO payload; // 依然存在重复，且强制包装
   }

   这种方法虽然将核心业务字段集中到了UserDTO，但并没有完全消除RequestUserDTO和ResponseUserDTO中对UserDTO的引用重复，更重要的是，它强制客户端在请求和响应体中引入一个额外的payload层级，增加了API的复杂性和客户端的适配成本。

统一DTO策略：简洁与高效

针对上述问题，一种更为简洁和高效的策略是：当请求和响应的核心业务数据结构一致，且响应只是在请求数据基础上增加元数据时，可以考虑使用一个统一的DTO来同时处理请求和响应。 该策略的核心思想是让业务实体DTO直接继承包含通用元数据的BaseResponseDTO。

// 基础响应DTO，包含通用元数据
public abstract class BaseResponseDTO {
    protected UUID id;
    protected Integer version;
    protected Date created;
    protected Date modified;
}

// 统一的用户DTO，继承BaseResponseDTO
public class UserDTO extends BaseResponseDTO {
    private String firstName;
    private String lastName;
}

在这种设计下：

• 作为请求体时：当UserDTO作为请求体发送到服务器时，其中继承自BaseResponseDTO的字段（如id、version、created、modified）通常会被Spring框架的Jackson等序列化/反序列化库自动忽略或处理为默认值，因为这些字段通常由服务器生成或维护，而非客户端提供。服务器端的业务逻辑会根据需要处理firstName和lastName，而无需关心那些响应特有的字段。
• 作为响应体时：当UserDTO作为响应体返回给客户端时，它将完整包含firstName、lastName以及继承自BaseResponseDTO的所有元数据字段，满足响应的需求。

这种方法的优势在于：

• 彻底消除代码重复：firstName和lastName只在一个地方定义。
• 简化模型：不再需要区分RequestUserDTO和ResponseUserDTO。
• 提升可维护性：业务字段的修改只需在一个DTO中进行。
• 客户端友好：请求和响应体结构扁平，无需额外的payload包装。

实施注意事项

虽然统一DTO策略带来了显著的优势，但在实际应用中仍需考虑以下几点：

1. 适用场景判断：
   • 适用：当请求体与响应体在核心业务字段上高度一致，且响应体仅比请求体多出少量通用元数据时。例如，创建/更新资源时，请求体是资源的完整数据，响应体在此基础上增加了ID、时间戳等。
   • 不适用：
     • 当请求体和响应体结构差异巨大，包含完全不同的字段集时。
     • 当请求体包含敏感信息（如密码），而响应体不应包含这些信息时。在这种情况下，仍建议使用独立的DTO，或者利用Jackson的@JsonIgnore、@JsonView等注解进行精细控制，但这会增加复杂性。
     • 当请求体需要进行严格的字段校验，而响应体字段不参与校验时。
2. 服务端校验：即使请求DTO包含了响应特有的字段，服务端也应始终对接收到的请求数据进行严格的业务和数据格式校验。例如，对于创建用户请求，即使UserDTO中存在id字段，也应确保在处理请求时该id字段被忽略或校验为null，因为id应由服务器生成。可以使用JSR 303/349 (Bean Validation) 注解结合Spring的@Valid进行校验。
3. API文档：清晰的API文档（如使用OpenAPI/Swagger）对于统一DTO的理解至关重要。文档应明确指出哪些字段在请求时是可选/忽略的，哪些是必填的。
4. 序列化/反序列化行为：Spring Boot默认使用的Jackson库在反序列化时，对于DTO中存在但请求JSON中不存在的字段，会赋予其默认值（如null）。对于JSON中存在但DTO中不存在的字段，默认会忽略。这为统一DTO的使用提供了便利。

总结

在RESTful API设计中，通过巧妙地利用Java的继承特性，将核心业务DTO与公共响应元数据DTO进行整合，可以有效解决请求与响应模型中的代码重复问题。这种统一DTO的设计模式，在特定场景下能够显著简化代码结构，提升开发效率和可维护性，同时保持API的简洁性和客户端友好性。在采纳此策略时，务必结合具体的业务需求和API契约，并辅以严谨的服务端校验和清晰的API文档。

终于介绍完啦！小伙伴们，这篇关于《优化APIDTO设计，降低代码重复率》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！