Consider a nicer API for configuring JsonOptions for minimal actions / route-to-code

[pranavkm]

Background and Motivation

The current way to configure JsonOptions for minimal is by configuring the Microsoft.AspNetCore.Http.Json.JsonOptions instance. From our docs, here's what this looks like:

using Microsoft.AspNetCore.Http.Json;

...
builder.Services.Configure<JsonOptions>(options =>
{
    options.SerializerOptions.IncludeFields = true;
});

Note that

a) You have to include a not too well-known namespace
b) There's also a Microsoft.AspNetCore.Mvc.JsonOptions type in the framework, so if you had previously imported the Mvc namespace, you'd be configuring the wrong JsonOptions type.

This makes it ripe for failure. We could consider adding a first class helper API to allow configuring this

Proposed API

namespace Microsoft.AspNetCore.Http;
public static HttpJsonServiceCollectionExtensions
{
    /// <summary>Configures options used for reading and writing JSON by route handlers, <c>HttpRequest.GetFromJsonAsync</c> and <c>HttpResponse.WriteJsonAsync</c>. </summary>
    public static IServiceCollection ConfigureHttpJsonOptions(this IServiceCollection serviceCollection, Action<JsonOptions> configureAction);
}

Usage Examples

var builder = WebApplication.CreateBuilder(args);
builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.IncludeFields = true;
});

Alternative Designs

• We could try and unify the HTTP and MVC options, but that seems like a much trickier proposition since both options can be configured independently today.

Risks

Users might be confused why configuring this option does not affect controller actions since this is API is much more accessible. I feel a documentation page that describes all the different JSON things that can be configured in ASP.NET Core might help mitigate this.

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.