FastEndpoints 框架中响应状态码注解的支持解析

背景介绍

在 FastEndpoints 这个高性能的.NET Web API 框架中，开发者经常需要为API端点定义明确的HTTP响应状态码。传统上，开发者需要在端点类中直接调用SendAsync方法时指定状态码，但很多.NET开发者更习惯使用注解(Attribute)的方式来声明响应状态码，特别是来自ASP.NET Core MVC背景的开发者。

问题发现

在早期版本的FastEndpoints中，当开发者尝试使用ProducesResponseType或SwaggerResponse注解来声明响应状态码时，框架无法正确识别这些注解，甚至会导致NSwag工具在生成OpenAPI/Swagger文档时抛出错误。例如，当开发者尝试为一个创建资源的端点添加201 Created状态码时，会遇到注解被忽略的问题。

解决方案实现

FastEndpoints团队在v6.0.0-beta.6版本中解决了这个问题，现在框架能够原生支持这两种常用的响应状态码注解：

1. ASP.NET Core的ProducesResponseType注解

[HttpPost("/api/post201")]
[ProducesResponseType(StatusCodes.Status201Created)]
public sealed class CreatedEndpoint : EndpointWithoutRequest
{
    public override async Task HandleAsync(CancellationToken c)
    {
        await SendAsync("Created", StatusCodes.Status201Created);
    }
}

2. Swagger的SwaggerResponse注解

[HttpPost("/api/post201")]
[SwaggerResponse(201)]
public sealed class CreatedEndpoint : EndpointWithoutRequest
{
    public override async Task HandleAsync(CancellationToken c)
    {
        await SendAsync("Created", StatusCodes.Status201Created);
    }
}

技术细节

注解处理机制

FastEndpoints现在会在构建API文档时检查端点类上的这些注解，并将它们整合到生成的OpenAPI规范中。这意味着：

• 注解中声明的状态码会被正确反映在Swagger UI中
• 框架会确保实际响应与注解声明保持一致
• 开发者可以混合使用注解和代码方式来定义响应

兼容性考虑

框架保持了向后兼容性，开发者仍然可以使用传统的代码方式来定义响应状态码。注解方式只是提供了额外的声明式选项，特别适合：

• 需要与现有ASP.NET Core MVC项目保持一致的团队
• 喜欢声明式编程风格的开发者
• 需要更清晰API文档的场景

最佳实践

虽然框架现在支持这两种注解方式，但在FastEndpoints中推荐的做法是：

1. 对于简单的状态码，直接在SendAsync方法中指定
2. 对于需要特别强调或文档化的状态码，使用注解补充说明
3. 保持一致性 - 在项目中统一使用一种风格或明确约定何时使用哪种方式

总结

FastEndpoints对响应状态码注解的支持增强了框架的灵活性和与其他.NET生态系统的互操作性。这一改进使得从ASP.NET Core MVC迁移到FastEndpoints更加平滑，同时也为需要精细控制API文档的团队提供了更多选择。开发者现在可以根据项目需求和个人偏好，自由选择最适合的方式来定义API的响应契约。