ASP.NET Web API中DTO的Id属性如何合理处理以避免客户端混淆？

先看这个简单的UserDTO：

public record UserDTO(string Id, string Username);

这个DTO会带来一个问题：在Swagger UI里，POST请求会要求客户端同时传入Id和Username，但实际上Id在创建用户的场景下根本不会被使用，容易让客户端产生困惑；但在GET请求中，Id又是响应里必不可少的属性。

先梳理已有方案的局限性：

• 仅使用Username字符串作为POST请求参数：当前简单场景可行，但如果后续需要添加更多属性，参数会变得杂乱无章，难以维护。
• 为POST和GET分别创建独立DTO：虽然职责清晰，但会产生大量重复代码，冗余度高。

下面是更合理的替代方案：

方案1：通过特性控制属性的绑定与序列化 #

在ASP.NET Core中，利用[BindNever]特性标记不需要在模型绑定中接收的属性，同时不影响其序列化输出：

public record UserDTO(
    [property: BindNever] string Id, 
    string Username
);

这样POST请求的Swagger文档里就不会要求传入Id，而GET请求返回响应时Id会正常序列化输出，完美适配两种场景，且无需额外创建新的DTO。

如果需要更精细的JSON序列化控制（比如使用System.Text.Json），还可以配合条件忽略特性：

public record UserDTO(
    [property: JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingDefault)] 
    string Id, 
    string Username
);

这种方式下，当Id为默认值（比如null）时会被忽略（对应POST请求的输入），而当Id有值时会正常序列化（对应GET请求的输出）。

方案2：基于继承的DTO分层 #

创建一个基础DTO包含共用属性，再分别扩展出创建（POST）和响应（GET）专用的DTO，既减少冗余，又明确区分场景：

// 基础DTO，包含共用属性
public record BaseUserDTO(string Username);

// POST请求专用，仅包含创建所需属性
public record UserCreateDTO : BaseUserDTO;

// GET请求专用，包含响应所需的全部属性
public record UserResponseDTO : BaseUserDTO
{
    public string Id { get; init; }
}

这种方式语义清晰，每个DTO的职责明确，适合中大型项目长期维护，后续扩展属性时也只需在对应层级添加即可。

方案3：使用映射器简化转换 #

如果已经在使用AutoMapper这类对象映射工具，可以用一个核心DTO，再配合映射配置处理不同场景的属性映射：

1. 定义核心UserDTO：

public record UserDTO(string Id, string Username);

2. 在AutoMapper配置中，针对POST场景忽略Id的映射：

CreateMap<UserCreateRequest, UserDTO>()
    .ForMember(dest => dest.Id, opt => opt.Ignore());

3. GET场景则正常映射所有属性。
   这种方式适合已经引入映射工具的项目，无需修改DTO结构，通过配置即可适配不同请求场景。

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