将@PathVariable的值存入@RequestBody对象是否为良好实践？

这种做法是可接受的，但要结合场景考量利弊，具体分析如下：

合理的一面 #

• 契合业务需求：需要将路径参数与请求体数据绑定后存入SQS，这种方式无需额外构造新的DTO，减少了代码冗余
• 安全性有保障：通过@JsonProperty(access = JsonProperty.Access.READ_ONLY)标记bankId和branchId，确保这两个字段不会被客户端传入的数据覆盖，保证了数据的一致性——毕竟这两个标识本就应该由路径参数决定，而非客户端提交内容

需要注意的潜在问题 #

• 职责耦合：BankDetails类同时承担了「客户端请求载体」和「内部队列消息载体」两个职责，如果后续客户端提交字段与队列所需字段差异扩大，这种耦合会提升维护成本
• 语义清晰度：路径参数已经明确了bank_id和branch_id的归属，但将其再存入请求体对象中，可能会让其他开发者对这两个值的来源产生疑惑，需要在代码中添加清晰的注释说明

优化建议 #

• 拆分DTO类：可以考虑分开定义BankDetailsRequest（仅包含address、zip，用于接收客户端请求）和BankDetailsMessage（包含address、zip、bankId、branchId，用于SQS消息），在接口层完成两者的转换，符合单一职责原则
• 简化转换逻辑：使用MapStruct等工具自动处理DTO之间的字段映射，减少手动赋值的重复代码

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