Extend the ability to customize parameter binding for Minimal APIs

[DamianEdwards]

This issue is to discuss future updates to extend the ability to customize parameter binding for Minimal APIs, beyond what's available in .NET 6, i.e. static methods bool TryParse(string input, out T value) and ValueTask<object> BindAsync(HttpContext httpContext) on the target type.

These are some features of parameter binding to consider:

• bind via target type (sync from request non-body sources, this is TryParse in .NET 6)
• bind via target type (async from request inc. body, this is BindAsync in .NET 6)
• bind via registered type (inc. overwriting built-in binders), e.g. register IParameterBinder<T> in DI
• bind per parameter, e.g. ([Binder(typeof(CustomerBinder))]Customer customer) => { }
• register via DI and accept services from DI
• have access to method/parameter info (i.e. callsite details, access to the parameter is supported by BindAsync in .NET 6 now)
• compose with other binders (e.g. composite binders)
• emit/mutate endpoint metadata, e.g. for OpenAPI
• AOT friendliness

Strawman

public interface IParameterBinderFactory<T>
{
    IParameterBinder<T> Create(IServiceProvider provider, ParameterInfo parameter, MethodInfo method);
}

public interface IParameterBinder<T>
{
    ValueTask<T> BindAsync(HttpContext httpContext);
}

Example usage:

var builder = WebApplication.CreateBuilder();

builder.Services.AddSingleton<IParameterBinderFactory<Customer>, CustomerBinder>();

var app = builder.Build();

app.MapPost("/customers", (Cusomter customer) =>
{
   return Results.Created(customer);
});

public class CustomerBinder : IParameterBinderFactory<Customer>, IParameterBinder<Customer>
{
    public CustomerBinder Create(IServiceProvider provider, ParameterInfo parameter, MethodInfo method)
    {
        // Called at application startup, access to parameter and method here to change behavior based on
        // naming, attributes, etc.
        return new CustomerBinder();
    }

    public async ValueTask<Customer> BindAsync(HttpContext httpContext)
    {
        // Called per invocation of routing delegate, i.e. per request
        // Do whatever custom binding logic desired, including reading from request body, etc.
        return await httpContext.Request.ReadAsJsonAsync<Customer>();
    }
}

Related issues:

• Minimal APIs ModelBinderProvider #33955
• Add support for custom model binders in minimal APIs #35472
• Minimal API query & route parameter mapping to an object #35304

[mumby0168]

This looks cool, assuming this would allow for a generic binder for say route/query parameters that takes an object looks at it's properties and tries to match them based on the route/query parameters?

Then it would be a case doing something like this:

var builder = WebApplication.CreateBuilder();

builder.Services.AddRoutingDelegateParameterBinder<RouteParameterBinder<Foo>>();
builder.Services.AddRoutingDelegateParameterBinder<RouteParameterBinder<Bar1>>();
builder.Services.AddRoutingDelegateParameterBinder<QueryParameterBinder<Bar>>();

var app = builder.Build();

[davidfowl]

This looks cool, assuming this would allow for a generic binder for say route/query parameters that takes an object looks at it's properties and tries to match them based on the route/query parameters?

You get to look at anything, we give you the HttpContext. If you want to use the double generic then that's up to you.

Some thoughts:

• We need to make sure this can be AOT friendly. Right now, the generic design forces the framework code to also be generic to avoid reflection. This might be fine if we end up using generics everywhere, otherwise we'll need to de-generic this API.
  • If we make the API non-generic then we need to deal with the performance costs of boxing everything.
• Another downside of making the API generic is that it forces users into using reflection to build composite binders (maybe that's OK?)
• We need to decide if we're going to allow replacing the built-in builders with these.
• We need to figure out how to expose metadata from custom binders to api explorer. MVC has a similar problem today (your number 8)
• Can you fallback to default behavior if you configure one of these binders but the parameter doesn't match the criteria? (e.g missing an attribute)

[mumby0168]

This looks cool, assuming this would allow for a generic binder for say route/query parameters that takes an object looks at it's properties and tries to match them based on the route/query parameters?

You get to look at anything, we give you the HttpContext. If you want to use the double generic then that's up to you.

Some thoughts:

• We need to make sure this can be AOT friendly. Right now, the generic design forces the framework code to also be generic to avoid reflection. This might be fine if we end up using generics everywhere, otherwise we'll need to de-generic this API.

  • If we make the API non-generic then we need to deal with the performance costs of boxing everything.

• Another downside of making the API generic is that it forces users into using reflection to build composite binders (maybe that's OK?)

• We need to decide if we're going to allow replacing the built-in builders with these.

• We need to figure out how to expose metadata from custom binders to api explorer. MVC has a similar problem today (your number 8)

• Can you fallback to default behavior if you configure one of these binders but the parameter doesn't match the criteria? (e.g missing an attribute)

Yeah, that certainly makes sense, I suppose the thought on generic is worth considering since this is aimed at people new to the language trying to get into C#. This could be a step too far or maybe a really good way to introduce generics as they are in my opinion required fairly early on now with many packages/libraries. Personally always like a generic approach.

On your last point, I would say that if something has been registered then if it fails to match to that method of parsing the incoming request for it to fall back to a default method could add confusion. That is from the viewpoint of when registering a different binder you intended for it to be handled differently.

This is really cool though, would love to get involved when this is ready to be worked on 👍