Support more ProblemDetails Titles out-of-the-box for Results.Problem()

[martincostello]

Is your feature request related to a problem? Please describe.

If a developer using Minimal Actions uses the Results.Problem() method with an HTTP status code that is not part of ProblemDetailsDefaults by default, then without it being explicitly set themselves, a default title is not returned in the response.

Take the following intentionally obscure example:

var builder = WebApplication.CreateBuilder(args);

var app = builder.Build();

app.MapGet("/teapot", () => Results.Problem("I like tea", statusCode: 418));

app.Run();

Calling the /teapot resource will return the following JSON:

{"status":418,"detail":"I like tea"}

If more default HTTP status codes were built in, the default experience would be more informative:

{"title":"I'm a teapot","status":418,"detail":"I like tea"}

Describe the solution you'd like

A more comprehensive list of HTTP status code descriptions are available in the ReasonPhrases class.

However, using it directly in ObjectResult here is not possible as Microsoft.AspNetCore.WebUtilities is not referenced by Microsoft.AspNetCore.Http.Results.

The out-of-the-box experience for Results.Problem() could be improved with one of the following:

1. Make Microsoft.AspNetCore.Http.Results reference Microsoft.AspNetCore.WebUtilities, and then use ReasonPhrases.GetReasonPhrase(string) as a fallback.
2. Refactor the HTTP status code descriptions into shared source, and then have both assemblies use it to enhance ObjectResult and/or ProblemDetailsDefaults and to provide the implementation for ReasonPhrases.GetReasonPhrase(string).

Otherwise, the developer has to manually specify the title for any HTTP status codes not already catered for, like this:

// using Microsoft.AspNetCore.WebUtilities;
app.MapGet("/teapot", () => Results.Problem("I like tea", statusCode: 418, title: ReasonPhrases.GetReasonPhrase(418)));

Additional context

Found using .NET SDK version 6.0.100-rc.1.21460.8

[rafikiassumani-msft]

Triage: We will re-evaluate this during .NET7 planning.

[martincostello]

@brunolins16 Would your changes in #42384 make this easier to implement with things being moved around in the layers? If you think it does I'll take a look once your PR gets merged.

[brunolins16]

@martincostello probably not but let me check how close we are, because I did not know about this issue before. Thanks.

[GREsau]

I've run into this problem, so an improvement here would be very nice. When I implemented an API Gateway using YARP, it came as a bit of a surprise that Results.Problem(statusCode: 502) produced such an empty response.

Would it also be worth adding more default types? So e.g. the 418 example above may result in:
{"title":"I'm a teapot","status":418,"detail":"I like tea","type":"https://tools.ietf.org/html/rfc2324#section-2.3.2"}

[martincostello]

I'd be happy to take a stab at implementing the changes for this if the aspnetcore team could give a steer as to a solution to the layering question at the top. Of course if it's too big a change to do at this stage without other changes, then it can stay here in the backlog.

[brunolins16]

@martincostello I'd be more than happy to help on it.

I did not participate in the decision of creating the ProblemDetailsDefaults and not reuse the ReasonPhrases class but, in my opinion, I totally agree with you, and I don't see a reason why we couldn't reference WebUtilities from other layers (again I might have been missing some aspect of this change).

I like this approach:

Refactor the HTTP status code descriptions into shared source, and then have both assemblies use it to enhance ObjectResult and/or ProblemDetailsDefaults and to provide the implementation for ReasonPhrases.GetReasonPhrase(string).

The very initial simple idea that I have in mind, would love to hear @dotnet/minimal-apis thoughts, is change the Phrases dictionary to include the Reference URL without changing how the GetReasonPhrase works, since it is a public API, and maybe expose another public API that expose both information. With that we can update the ProblemDetailsDefaults to use this new method in Apply instead the dictionary owned by ProblemDetailsDefaults (that could be removed).

I see it as a simple change if no problem referencing WebUtilities.