Allow Custom JsonSerializerOptions for Minimal Actions

[Kahbazi]

Background and Motivation

Add ability to have custom JsonSerializerOptions for serializing and deserializing in minimal actions.

Proposed API

namespace Microsoft.AspNetCore.Builder
{
     public static class DelegateEndpointRouteBuilderExtensions
     {
+        public static DelegateEndpointConventionBuilder Map(
+            this IEndpointRouteBuilder endpoints,
+            RoutePattern pattern,
+            Delegate handler,
+            JsonSerializerOptions options)
    }
}

namespace Microsoft.AspNetCore.Http
{
     public sealed class RequestDelegateFactoryOptions
     {
+      public JsonSerializerOptions JsonSerializerOptions { get; init; }
     }
}

Usage Examples

var jsonOptions = new JsonSerializerOptions
{
    PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
};

app.Map("\action", () => MyAction(), jsonOptions);

Alternative Designs

This could also be added via Endpoint metadata in order to prevent all extra overloads (MapGet, MapPost, ...), but the downside is that it would add an extra fetch from Endpoint.Metadata for serializing and deserializing.

public static class DelegateEndpointRouteBuilderExtensions
{
+   public static DelegateEndpointConventionBuilder WithJsonOptions(
+       this DelegateEndpointConventionBuilder builder,
+       JsonSerializerOptions options)
}

Risks

[davidfowl]

No I don’t think we should do this. The options are:

• configure JsonOptions globally
• Use Results.Json and pass the options that way
• Call WriteAsJsonAsync and pass the options that way

[Kahbazi]

• configure JsonOptions globally

I thought there were no static global options for System.Text.Json.

• Use Results.Json and pass the options that way
• Call WriteAsJsonAsync and pass the options that way

Fair enough. The only thing left is for serializing from body which I guess BindAsync could be used for that. Although the code would be simpler if JsonOption could be set via the proposed API.

@davidfowl I have nothing more to add, the issue could be closed. 🙂

[davidfowl]

We should add a first class API to configure the JsonOptions. This isn't global for all calls, it's for calls to ReadAsJsonAsync and WriteAsJsonAsync

[Kahbazi]

Ah I see what you're talking about.

aspnetcore/src/Http/Http.Extensions/src/HttpRequestJsonExtensions.cs

Lines 189 to 193 in 8b30d86

	private static JsonSerializerOptions ResolveSerializerOptions(HttpContext httpContext)
	{
	// Attempt to resolve options from DI then fallback to default options
	return httpContext.RequestServices?.GetService<IOptions<JsonOptions>>()?.Value?.SerializerOptions ?? JsonOptions.DefaultSerializerOptions;
	}

So should I update the proposal to this one?

public static class ServiceCollectionExtensions
{
    /// <summary>
    /// Configures JsonOptions for WriteAsJsonAsync and ReadFromJsonAsync.
    /// </summary>
    public static IServiceCollection ConfigureJsonOptions(this IServiceCollection services, Action<Microsoft.AspNetCore.Http.Json.JsonOptions> action)
    {
        return services.Configure(action);
    }
}

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

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.

[rafikiassumani-msft]

@Kahbazi and @davidfowl We also have a namespace issue that we may need to address if we were to provide a first-class API to globally configure JsonSerializerOptions. Notice that the following Microsoft.AspNetCore.Http.Json.JsonOptions in your updated proposal is different from Microsoft.AspNetCore.Mvc.JsonOptions . This causes confusion to users who want to configure JsonOptions as the Http namespace one usually gets imported by the editor but may not achieve the intended user configuration objective.

@davidfowl Given the namespace issue, do we need to provide a first-class API to hide the code below and help avoid confusion?

  builder.Services.Configure<Microsoft.AspNetCore.Mvc.JsonOptions>(opts =>
  {
     //opts.JsonSerializerOptions.PropertyNamingPolicy = null;
     //More Configs if needed.
  
  });

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 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.

[Finickyflame]

If we can't use a specific JsonSerializerOptions per endpoint, how can we make sure the openAPI schema is generated correctly?

Even now (didn't look at dotnet 9) we have to synchronize both Microsoft.AspNetCore.Http.Json.JsonOptions and Microsoft.AspNetCore.Mvc.JsonOptions to make sure the OpenAPI schema generated by SwaggerGen is accurate.

Beeing able to specify the JsonSerializerOptions on an endpoint or a group of endpoints could bring so much flexibility. If the answer is still Results.Json, could we then have the ability to provide the JsonSerializerOptions in the Produces and Acccepts?

[giammin]

This could be really useful in certain scenarios.

I came across this because I need to deserialize a client request using a custom JsonConverter, and I would prefer not to add it globally but rather use it only for that specific endpoint.