Infer default sources for parameters in MapAction

[halter73]

How to determine each parameter's source

The numbered and lettered rules for determining the source of a parameter should be applied in the order. The bullet points are unordered.

1. If an attribute that implements one of the "IFrom..." interfaces in Microsoft.AspNetCore.Http.Metadata is applied to the parameter, populate the parameter from the source specified by the attribute. Only one of these attributes can be specified per parameter, and these attributes must implement no more than one of these interfaces.
   • IFromRouteMetadata
     • Reads from HttpRequest.RouteValues[name] where name is specified by IFromRouteMetadata.Name or the parameter name if IFromRouteMetadata.Name is null.
   • IFromBodyMetadata
     • Reads from HttpRequest.Body(Reader) as JSON using HttpRequest.ReadFromJsonAsync<{ParameterType}>().
     • Can only be used once per parameter list (there's only one body)
     • Cannot be used in the same parameter list as IFromFormMetadata
     • Will cause requests with an empty body to be rejected without calling the action unless IFromBodyMetadata.AllowEmpty returns true. (The default interface implementation returns false.)
   • IFromFormMetadata
     • Reads from HttpRequest.Form[name] where name is specified by IFromFormMetadata.Name or the parameter name if IFromFormMetadata.Name is null.
     • Can be used multiple times in a single parameter list (presumably for different names)
     • Cannot be used in the same parameter list as IFromBodyMetadata (there's only one body)
   • IFromHeaderMetadata
     • Reads from HttpRequest.Headers[name] where name is specified by IFromHeaderMetadata.Name or the parameter name if IFromHeaderMetadata.Name is null.
   • IFromQueryMetadata
     • Reads from HttpRequest.Query[name] where name is specified by IFromQueryMetadata.Name or the parameter name if IFromQueryMetadata.Name is null.
   • IFromServiceMetadata
     • Normally resolves via HttpRequest.RequestServices.GetRequiredService<{ParameterType}>().
     • If the parameter is a nullable reference type (i.e. has the System.Runtime.CompilerServices.NullableAttribute), resolve via HttpRequest.RequestServices.GetService<{ParameterType}>().
     • If the parameter is optional (i.e. has a default value), resolve via HttpRequest.RequestServices.GetService<{ParameterType}>() ?? parameter.DefaultValue.
2. If the parameter is a scalar value type that lives in the System namespace, first check HttpRequest.RouteValues contains an entry for the parameter name. If it does, use HttpRequest.RouteValues[{ParameterName}]. Otherwise, use HttpRequest.Query[{ParameterName}].
   • TODO: Come up with actual list of scalar value types that live in the System namespace.
   • Question: Do we want to allow types to opt-in to this? Today MVC uses TypeConverter which is hard to implement.
   • Alternatives:
     • Something convention-based like the presence of a bool TryParse(string, out T) method
     • The explicit implementation of an interface with that method to make it more opt in
3. If HttpRequest.RequestServices.GetService<{ParameterType}>() is not null, use that value.
   • TODO: Figure out how to make this work well with compile-time source generation. This might need to be determined at runtime no matter what.
4. Otherwise, treat the parameter as if it had an attribute implementing IFromBodyMetadata where IFromBodyMetadata.AllowEmpty is false.

How we will convert to the parameter type.

1. For parameters bound from the body (has an IFromBodyMetadata attribute or is treated by such by convention), we will continue to assume JSON and initialize the parameter with HttpRequest.ReadFromJsonAsync<{ParameterType}>().
   • We need to figure out if we want make this configurable or force people to read they body themselves if they want configurability. If we decide on configurability, we need to decide on how much.
2. For all other parameters bound from the request (i.e. not a service or from the body) we need to convert from a string.
   • Since there is a finite list of "scalar value who lives in the System namespace" we'll bind to by convention, we'll use their TryParse methods or equivalent until we decide on something different for those.
   • Parameters explicitly bound by attribute to a string-based source also need to be converted much like those read from the RouteValues or Query by convention. I doubt we also want to limit these parameter types to a finite list. For now, we'll continue doing what we do today to convert from string as described below.

How we convert to the parameter type today in the "MapAction" APIs

Today, all inputs are converted to their respective parameter types as follows:

1. For parameters bound from the body, we already call HttpRequest.ReadFromJsonAsync<{ParameterType}>().
2. All other parameters start as strings from the various sources listed above.
   1. If {ParameterType} is string, we're done!
   2. If there's a {ParameterType}.Parse({ValueString}) method, use that.
      • NOTE: Going forward, prefer/require TryParse instead.
   3. Lastly, try Convert.ChangeType({ValueString}, typeof{ParameterType}, CultureInfo.InvariantCulture)
      • NOTE: Going forward, we should stop using CultureInfo.InvariantCulture

Original issue:

1. Complex type -> FromBody (See https://source.dot.net/#Microsoft.AspNetCore.Mvc.Abstractions/ModelBinding/ModelMetadata.cs,606)
2. Name appears as a route value -> FromRoute
3. Everything else -> FromQuery

From: #29878 (comment)

New inference rules unique to MapAction:

1. [FromServices] should work implicitly for types that can be resolved from RequestServices.

[halter73]

As part of this let's make sure optional parameters work well and that there are good error logs when non-optional parameters are missing.

Fixed by #30434

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Kahbazi]

@halter73 Do you accept PR for this if the requirement is final?

[halter73]

I'd be happy to accept a PR from you for this @Kahbazi. Thanks for all the MapAction help already! No promises we don't change the design a little down the road ofc.

[halter73]

1. I own the type and define the Parse method I want which is used by convention.
2. I don't own the type, but I want to change how it's parsed.
   1. Option 1: Add attribute to parameter.
   2. Option 2: Add attribute to assembly that applies to all parameters to a specified type.
      1. Does this only apply to call sites in that are in the same assembly?
   3. Option 3: Scan assembly or source for implementation of a specific interface (e.g. IParameterConverter).
   4. Option 4: Add a TypeConvert like service at runtime (Rejected: cannot adequately optimize at compile time).

[charlesroddie]

Please don't put a convention-based approach in such a core dotnet library as ASP.Net. It's true that there is a precedent for convention-based approaches from EF but EF is not such a core library since it is easy to avoid unlike ASP.Net.

[davidfowl]

Please don't put a convention-based approach in such a core dotnet library as ASP.Net. It's true that there is a precedent for convention-based approaches from EF but EF is not such a core library since it is easy to avoid unlike ASP.Net.

ASP.NET Core already have the un-opinionated layer you're looking for, this isn't that component.

[halter73]

Follow up based on yesterday's meeting discussing #31603:

• Look for TryParse on method on any parameter first, signatures supported:
  • For enums, use static bool Enum.TryParse<T>(string, out T).
  • Special case for some built-in types:
    • ex: static bool TryParse(string, NumberStyles, IFormatProvider, int) where the NumberStyles parameter is required to use CultureInfo.InvariantCulture as the IFormatProvider.
  • static bool TryParse(string, IFormatProvider, out T)
  • static bool TryParse(string, out T)
• Use invariant culture always (and will wait for feedback)
• Assume interfaces are services, classes will require an explicit [FromServices]
• Assume classes are from the body
• Remove form as a source