请求提供.NET Core REST API薪资字段兼容Int/Float双客户端的方案

1. API版本化（推荐方案） #

创建两个版本的API，完全隔离新旧客户端的需求：

• v1 API：保留原有逻辑，薪资字段为Integer类型，兼容现有客户端的全量CRUD操作。数据库仍映射Integer字段，读写直接处理整数类型。
• v2 API：将薪资字段改为Float类型，适配新客户端的CRUD操作。若数据库未完成类型切换，可在业务层做类型转换（读取int后转float返回，写入时将float转int存入；后续数据库改为float后直接映射即可）。

实现细节：

• 通过路由前缀区分版本，比如/api/v1/employees和/api/v2/employees
• 为两个版本创建独立DTO：
  • EmployeeV1Dto：薪资字段定义为int
  • EmployeeV2Dto：薪资字段定义为float
• 核心业务逻辑复用，仅在DTO与实体的转换层处理类型差异

优点：边界清晰，新旧客户端互不影响，后续数据库切换后v1可通过类型转换继续兼容，直到老客户端完全退役。

2. 基于请求标识的内容协商 #

若不想维护多版本API，可通过请求头或查询参数动态适配薪资类型：

• 客户端请求时携带标识，比如自定义头X-Salary-Type: int/float或查询参数salaryType=int
• API根据标识动态处理字段：
  • 老客户端请求：将数据库值（int或后续的float）转为int返回；写入时将传入的int转为对应数据库类型存储
  • 新客户端请求：直接返回float类型；写入时将传入的float转为对应数据库类型存储

实现细节：

• 自定义JSON转换器，结合HttpContext获取的请求标识，在序列化/反序列化时调整薪资字段类型
• 业务层统一处理类型转换逻辑，避免重复代码

优点：无需维护多套API，适合客户端数量少、差异小的场景；缺点：逻辑耦合度高，后续扩展复杂度提升。

3. 数据库过渡方案（配合上述方案） #

如果计划将数据库薪资字段从Integer改为Float，可按以下步骤平滑过渡：

1. 数据库新增Float类型字段（如SalaryFloat），保留原有SalaryInt字段
2. 写入数据时同步更新两个字段（int转float存入SalaryFloat，float转int存入SalaryInt）
3. v1 API读取SalaryInt，v2 API读取SalaryFloat
4. 待老客户端全部退役后，删除SalaryInt字段，统一使用SalaryFloat

此方案可避免数据库变更直接影响老客户端，实现无缝迁移。

关键注意事项 #

• 处理类型转换时需明确精度规则：比如float转int时是截断还是四舍五入，需与业务方确认
• 数据库切换为float后，v1 API写入时需将传入的int转为float存储，返回时再转回int，确保老客户端兼容性

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