IResult support in MVC

[brunolins16]

Background and Motivation

Today, with the new Microsoft.AspNetCore.Http.Results class is very easy to get confused and implement a Controller Action similar with that, or any other variation of the methods exposed by this class:

[HttpGet]
public IResult Get()
{
    return Results.Ok();
}

Also, is very easy to use an Microsoft.AspNetCore.Http.IResult custom implementation as a return of a controller action, like this:

public class MyCustomResult : IResult
{
    public Task ExecuteAsync(HttpContext httpContext) => Task.CompletedTask;
}

[HttpGet]
public IResult Get()
{
    return new MyCustomResult();
}

Both examples will not throw exception but will serialize the class. For the first example the action will return the following payload:

{
  "value": null,
  "statusCode": 200,
  "contentType": null
}

Proposed API

The proposal is the creation of a new public action result that will store an instance of the IResult and call the IResult.ExecuteAsync method instead instead of using the IActionResultExecutor to write the Http Response. With this, we will miss all the content-negotiation available in MVC through the ObjectResultExecutor but we will have the correct serialization and all the other components, like Middleware, Filters etc., will work.

+namespace Microsoft.AspNetCore.Mvc;

+public class HttpResultsActionResult : ActionResult
+{
+    public IResult Result { get; }
+    public MinimalActionResult(IResult result){}
+    public override Task ExecuteResultAsync(ActionContext context){}
+}

The controller's action can return a Microsoft.AspNetCore.Http.IResult that will be converted to the new HttpResultsActionResult when the ActionResultTypeMapper.Convert is invoked. Eg.:

[HttpGet]
public IResult Get() => Results.Ok(new Todo() { Id = 1, Title = "Sample todo"});

The sample action will produce the following payload:

{
  "id": 1,
  "title":  "Sample todo"
}

Usage Examples

Controller's action using the HttpResultsActionResult

    [HttpGet()]
    public ActionResult Get(int id)
    {
        var result = Results.Ok(new Contact() { ContactId = id });
        return new HttpResultsActionResult(result);
    }

Result's filter using the HttpResultsActionResult

public class HttpResultResultFilter : IResultFilter
{
    public void OnResultExecuted(ResultExecutedContext context)
    {
        if (context is { Result: HttpResultsActionResult { Result: IResult httpResult } })
        {
            // Do something after the result executes.
        }        
    }
}

If the proposal #40656 is approved, the results instance could be further inspected, eg.:

public class HttpResultResultFilter : IResultFilter
{
    public void OnResultExecuted(ResultExecutedContext context)
    {
        if (context is
            {
                Result: HttpResultsActionResult
                { Result: IStatusCodeHttpResult { StatusCode: StatusCodes.Status200OK } }
            })
        {
            // Do something after the result executes.
        }      
    }
}

Alternative Designs

The new type could have a private constructor, that could avoid undesired instantiation

+namespace Microsoft.AspNetCore.Mvc;

+public class HttpResultsActionResult : ActionResult
+{
+    public IResult Result { get; }
+    public override Task ExecuteResultAsync(ActionContext context){}
+}

Or the new action result could be internal instead, that will make this proposal irrelevant, but the feature will be available, however, will not be possible to create Result Filters as shown in the example.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[halter73]

API Review Notes

• Should the new type and constructor be public?
  • Yes for the type, because it could be useful for filters
  • Yes for the constructor. Even though no one should really call it, this is expected for ActionResult implementations.
• What about renaming the type not to include "Result" twice?

+namespace Microsoft.AspNetCore.Mvc;

+public class HttpActionResult : ActionResult
+{
+    public IResult Result { get; }
+    public HttpActionResult(IResult result){}
+    public override Task ExecuteResultAsync(ActionContext context){}
+}

• The above might be too similar to https://docs.microsoft.com/en-us/previous-versions/aspnet/dn202095%28v%3dvs.118%29.
• We will continue to discuss naming of the public type in the next API review, but we can take the PR with the implicit conversion and the internal type for now.