Ability to enable API behavior globally

[khellang]

As mentioned in dotnet/aspnetcore#2846 (comment):

Is there a way to globally enable those conventions without using attributes? If not, I'd like to request it 😝 I only ever build APIs with MVC (there's never a V 😉) and would ❤ to avoid more attributes.

I did a quick scan through the code, but couldn't see how you'd enable the conventions without adding attributes. Is this something you'd consider a PR for?

[rynowak]

couldn't see how you'd enable the conventions without adding attributes. Is this something you'd consider a PR for?

Yeah, I'd love to find a way to do this 👍 What did you have in mind? (let's try to come up with a plausible idea first)

[khellang]

What did you have in mind? (let's try to come up with a plausible idea first)

I'm just thinking we can add a property, RequireApiControllerAttribute, to ApiBehaviorOptions and check that in ApiBehaviorApplicationModelProvider:

var isApiController = !_apiBehaviorOptions.RequireApiControllerAttribute || controllerModel.Attributes.OfType<IApiBehaviorMetadata>().Any();

It would also be nice if there was a UseApiConventions method, like this:

public static IMvcCoreBuilder UseApiConventions(this IMvcCoreBuilder builder, Action<ApiBehaviorOptions> configure)
{
    builder.Services.Configure<ApiBehaviorOptions>(options =>
    {
        options.RequireApiControllerAttribute = false;
        configure(options);
    });

    return builder;
}

A couple of things:

1. I realize that RequireApiControllerAttribute might be a bad name. Especially since ApiBehaviorApplicationModelProvider checks for attribute of type IApiBehaviorMetadata. Suggestions?
2. I'm torn on the UseApiConventions extension method as I'm not sure whether a user would think it's a way to only configure the conventions, and not apply them globally. Maybe XML docs can solve this?

What do you think? Am I too far out here?

[rynowak]

Sorry for letting this fall off my radar, I was off having other adventures.

The approach here seems pretty reasonable

[mkArtakMSFT]

@pranavkm, I'm assigning this to you to come up with the desired approach we'd like to take here for now.
As this is a low priority issue, we may leave it to be handled towards the end of the milestone, given we'll have enough time. Alternatively, @khellang, we'd be happy to accept a PR when we'll lock down on the approach.

[pranavkm]

Tangentially related to #7802, but we want to be able to try using tooling (specifically analyzers and codefixes) to help guide users in authoring their API actions. Configuring it using code (the RequireApiControllerAttribute property in your case) makes this problematic.

With the convention work, we ended with a solution of allowing an attribute to be placed on the assembly. It does cause you to have to specify it on a per-assembly basis, rather than on a per-application basis, but it seems like smaller price to pay. In this case, we could consider allowing the ApiController attribute to be applied to assemblies. The concern, as usual, is a way to opt-out of it i.e. if you want to specifically turn off the behavior for a controller. I'd start with not being super concerned about this, since we could always add a feature to support this scenario at a later time.

Thoughts \ concerns?

[pranavkm]

Moving it out to preview2. cc @glennc

[glennc]

@khellang do you care about this as much when a single attribute for the assembly enables the conventions? My hesitation here is, as @pranavkm talks about, we are walking a line that could easily lead to the analyzers not being able to function. Which might be fine for some people, but is generally an important part of the experience.

[khellang]

An assembly level attribute would probably work as well, but why introduce yet another way of configuring MVC?

[pranavkm]

Summarizing our offline chat about this -

• We want to be able to provide tooling experiences (analyzers \ codefixes) out of the box. This requires being able to statically configure the application.
• We'll refactor the ApiBehaviorApplicationModelProvider in to a convention per feature that it enables. These conventions are agnostic of ApiControllerAttribute and can be used to opt in to one or more of the behaviors that ApiControllerAttribute sets up. This should give users a way to continue configuring applications at runtime without having to use the attribute.
• We'll do a similar thing with similar attributes - the default behavior would be enabled by the presence of the attribute, but we'll provide an experience to configure it at runtime (typically a convention or a knob on the ApplicationModel)