从显式类型的 ASP.NET Core API 控制器（不是 IActionResult）返回 404

Question

ASP.NET Core API 控制器通常返回显式类型（如果您创建新项目，默认情况下会返回），类似于：

[Route("api/[controller]")]
public class ThingsController : Controller
{
    // GET api/things
    [HttpGet]
    public async Task<IEnumerable<Thing>> GetAsync()
    {
        //...
    }

    // GET api/things/5
    [HttpGet("{id}")]
    public async Task<Thing> GetAsync(int id)
    {
        Thing thingFromDB = await GetThingFromDBAsync();
        if(thingFromDB == null)
            return null; // This returns HTTP 204

        // Process thingFromDB, blah blah blah
        return thing;
    }

    // POST api/things
    [HttpPost]
    public void Post([FromBody]Thing thing)
    {
        //..
    }

    //... and so on...
}

问题在于 return null; - 它返回一个 HTTP 204：成功，没有内容。

这被很多客户端Javascript组件认为是成功的，所以有这样的代码：

const response = await fetch('.../api/things/5', {method: 'GET' ...});
if(response.ok)
    return await response.json(); // Error, no content!

在线搜索（例如this question 和this answer）指向有用的控制器扩展方法return NotFound();，但所有这些都返回IActionResult，这与我的Task<Thing> 返回类型不兼容。该设计模式如下所示：

// GET api/things/5
[HttpGet("{id}")]
public async Task<IActionResult> GetAsync(int id)
{
    var thingFromDB = await GetThingFromDBAsync();
    if (thingFromDB == null)
        return NotFound();

    // Process thingFromDB, blah blah blah
    return Ok(thing);
}

这行得通，但要使用它，必须将 GetAsync 的返回类型更改为 Task<IActionResult> - 显式类型丢失，并且控制器上的所有返回类型都必须更改（即在all) 或者会有一些操作处理显式类型而其他操作的混合。此外，单元测试现在需要对序列化做出假设，并明确反序列化 IActionResult 的内容，在它们具有具体类型之前。

有很多方法可以解决这个问题，但它似乎是一个很容易设计出来的令人困惑的混搭，所以真正的问题是：ASP.NET Core 设计者想要的正确方法是什么？

似乎可能的选项是：

1. 根据预期的类型，有一个奇怪的（测试混乱）显式类型和 IActionResult 的组合。
2. 忘记显式类型吧，Core MVC 并不真正支持它们，总是使用IActionResult（在这种情况下，它们为什么会出现？）
3. 编写HttpResponseException 的实现并像ArgumentOutOfRangeException 一样使用它（有关实现，请参见this answer）。但是，这确实需要对程序流使用异常，这通常是个坏主意，而且deprecated by the MVC Core team。
4. 编写一个 HttpNoContentOutputFormatter 的实现，为 GET 请求返回 404。
5. Core MVC 的工作方式还缺少什么？
6. 或者对于失败的 GET 请求，204 正确而 404 错误是否有原因？

这些都涉及妥协和重构，会丢失一些东西或增加一些看起来不必要的复杂性，与 MVC Core 的设计不一致。哪种妥协是正确的，为什么？

Answer 1

这是addressed in ASP.NET Core 2.1 和ActionResult<T>：

public ActionResult<Thing> Get(int id) {
    Thing thing = GetThingFromDB();

    if (thing == null)
        return NotFound();

    return thing;
}

甚至：

public ActionResult<Thing> Get(int id) =>
    GetThingFromDB() ?? NotFound();

我将在实施后更详细地更新此答案。

原答案

在 ASP.NET Web API 5 中有一个 HttpResponseException（正如 Hackerman 指出的那样），但它已从 Core 中删除，并且没有中间件来处理它。

我认为这种变化是由于 .NET Core - ASP.NET 尝试开箱即用地做所有事情，而 ASP.NET Core 只做你明确告诉它的事情（这是它如此重要的一个重要部分更快、更便携）。

我找不到执行此操作的现有库，因此我自己编写了它。首先我们需要一个自定义异常来检查：

public class StatusCodeException : Exception
{
    public StatusCodeException(HttpStatusCode statusCode)
    {
        StatusCode = statusCode;
    }

    public HttpStatusCode StatusCode { get; set; }
}

然后我们需要一个 RequestDelegate 处理程序来检查新异常并将其转换为 HTTP 响应状态代码：

public class StatusCodeExceptionHandler
{
    private readonly RequestDelegate request;

    public StatusCodeExceptionHandler(RequestDelegate pipeline)
    {
        this.request = pipeline;
    }

    public Task Invoke(HttpContext context) => this.InvokeAsync(context); // Stops VS from nagging about async method without ...Async suffix.

    async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await this.request(context);
        }
        catch (StatusCodeException exception)
        {
            context.Response.StatusCode = (int)exception.StatusCode;
            context.Response.Headers.Clear();
        }
    }
}

然后我们在Startup.Configure注册这个中间件：

public class Startup
{
    ...

    public void Configure(IApplicationBuilder app)
    {
        ...
        app.UseMiddleware<StatusCodeExceptionHandler>();

最后，动作可以抛出 HTTP 状态码异常，同时仍然返回一个显式类型，无需从 IActionResult 转换即可轻松进行单元测试：

public Thing Get(int id) {
    Thing thing = GetThingFromDB();

    if (thing == null)
        throw new StatusCodeException(HttpStatusCode.NotFound);

    return thing;
}

这会保留返回值的显式类型，并允许轻松区分成功的空结果 (return null;) 和因为找不到某些内容而导致的错误（我认为它就像抛出 ArgumentOutOfRangeException）。

虽然这是一个解决问题的方法，但它仍然没有真正回答我的问题 - Web API 的设计者构建了对显式类型的支持，并期望它们会被使用，添加了对 return null; 的特定处理，以便它会产生204而不是200，然后没有添加任何方法来处理404？添加这么基本的东西似乎需要做很多工作。

Answer 2

您实际上可以使用IActionResult 或Task<IActionResult> 代替Thing 或Task<Thing> 甚至Task<IEnumerable<Thing>>。如果您有一个返回 JSON 的 API，那么您只需执行以下操作：

[Route("api/[controller]")]
public class ThingsController : Controller
{
    // GET api/things
    [HttpGet]
    public async Task<IActionResult> GetAsync()
    {
    }

    // GET api/things/5
    [HttpGet("{id}")]
    public async Task<IActionResult> GetAsync(int id)
    {
        var thingFromDB = await GetThingFromDBAsync();
        if (thingFromDB == null)
            return NotFound();

        // Process thingFromDB, blah blah blah
        return Ok(thing); // This will be JSON by default
    }

    // POST api/things
    [HttpPost]
    public void Post([FromBody] Thing thing)
    {
    }
}

更新

似乎担心的是，在返回 API 时显式会有所帮助，虽然可能是 显式，但实际上并不是很有用。如果您正在编写执行请求/响应管道的单元测试，您通常会验证原始返回（很可能是 JSON，即；C#中的字符串>）。您可以简单地将返回的字符串转换回强类型等效项，以便使用Assert 进行比较。

这似乎是使用IActionResult 或Task<IActionResult> 的唯一缺点。如果你真的，真的想要明确并且仍然想设置状态码，有几种方法可以做到这一点 - 但它不被认可，因为框架已经有一个内置的机制，即；在Controller 类中使用IActionResult 返回方法包装器。不过，你可以写一些 custom middleware 来处理这个问题。

最后，我想指出，如果根据W3 API 调用返回null，则204 的状态码实际上是准确的。为什么你会想要一个 404？

204

服务器已完成请求，但不需要返回 实体主体，并且可能想要返回更新的元信息。这 响应可能包括新的或更新的元信息，形式为 entity-headers，如果存在应该与 请求的变体。

如果客户端是一个用户代理，它不应该改变它的文档视图 从导致发送请求的原因。这个回应是 主要目的是允许输入进行操作，而无需 导致用户代理的活动文档视图发生变化，尽管 任何新的或更新的元信息都应该应用于文档 当前在用户代理的活动视图中。

204 响应不能包含消息体，因此总是 由标题字段后的第一个空行终止。

我认为第二段的第一句话说得最好，“如果客户端是用户代理，它不应该改变导致发送请求的文档视图”。 API 就是这种情况。与 404 相比：

服务器没有找到任何匹配 Request-URI 的东西。不 指示该状况是暂时的还是 永恒的。如果服务器应该使用 410 (Gone) 状态码 通过一些内部可配置的机制知道，旧的 资源永久不可用且没有转发地址。 当服务器不希望这样做时，通常使用此状态码 准确说明请求被拒绝的原因，或者当没有其他请求时 响应是适用的。

主要区别是一个更适用于 API，另一个更适用于文档视图，即；显示的页面。

Answer 3

为了完成类似的事情（不过，我认为最好的方法应该是使用IActionResult），您可以按照throw 和HttpResponseException 进行操作，如果您的Thing 是null ：

// GET api/things/5
[HttpGet("{id}")]
public async Task<Thing> GetAsync(int id)
{
    Thing thingFromDB = await GetThingFromDBAsync();
    if(thingFromDB == null){
        throw new HttpResponseException(HttpStatusCode.NotFound); // This returns HTTP 404
    }
    // Process thingFromDB, blah blah blah
    return thing;
}

Answer 4

当我想针对发送到请求中的错误数据返回 400 响应时，对于如何处理强类型响应的问题，我也一直在寻找答案。我的项目在 ASP.NET Core Web API (.NET5.0) 中。我找到的解决方案基本上是设置状态码并返回对象的default版本。这是您的示例，其中将状态代码设置为 404 并在 db 对象为空时返回默认对象。

[Route("api/[controller]")]
public class ThingsController : Controller
{
    // GET api/things
    [HttpGet]
    public async Task<IEnumerable<Thing>> GetAsync()
    {
        //...
    }

    // GET api/things/5
    [HttpGet("{id}")]
    public async Task<Thing> GetAsync(int id)
    {
        Thing thingFromDB = await GetThingFromDBAsync();
        if(thingFromDB == null)
        {
            this.Response.StatusCode = Microsoft.AspNetCore.Http.StatusCodes.Status404NotFound;
            return default(Thing);
        }
        
        // Process thingFromDB, blah blah blah
        return thing;
    }

    // POST api/things
    [HttpPost]
    public void Post([FromBody]Thing thing)
    {
        //..
    }

    //... and so on...
}

Answer 5

有另一个相同行为的问题 - 所有方法都返回 404。问题在于缺少代码块

app.UseEndpoints(endpoints =>
{
    endpoints.MapControllers();
});