Users are forced to implement an interface to define composition handlers and are constrained to create multiple classes instead of defining multiple methods in the same composition handler class

[mauroservienti]

Depends on:

• Users cannot decorate composition handlers with the Route attribute to prefix routes #148
• Composition handlers are constrained to use only one routing attribute #287

Add support for conventions, if a class:

• is defined in a CompositionHandlers namespace
• has a method, whose name doesn't really matter, that takes the correct argument and returns the correct type
• has the expected Http*Attribute on the identified method

Then it's a composition handler. And stop making an interface a requirement. This could enable having handlers with multiple methods to group composition actions by use case for example.

[markphillips100]

Will an interface still be an option too do you think?

In the convention case, when defining the method, does the "correct argument" imply a convention also? Just curious how to introduce model bound parameters to a method.

[mauroservienti]

Will an interface still be an option too do you think?

Not necessarily. I was thinking about keeping the current design and adding the new option.

In the convention case, when defining the method, does the "correct argument" imply a convention also? Just curious how to introduce model bound parameters to a method.

The thing I was brainstorming goes something like this:

• when scanning assemblies scan for all types in a specific namespace (say for example *.Handlers)
• look for all the public methods that returns Task and are decorated with one of the routing attributes (e.g. HttpGet)
• for each them and compile an expression tree for each one to invoke them using a so called fast delegate approach
• as we're doing today build the endpoint using the template defined in attribute, by storing in the custom endpoint also the list of parameters (using something like a parameter descriptor)

At invocation time:

• bind the parameters stored in the endpoint
  • throw of some titles badly
• use the compiled expression tree to invoke the user defined method passing the arguments returned by the bind operation

[markphillips100]

I like it @mauroservienti . So in theory you could get as near to controller action parameter behaviour. For example, not limit a method to just a model object but actual individual parameters with their own model binding attributes:

[HttpPost("cart/{orderId:guid}")]
Task PlaceOrder(HttpRequest httpRequest, [FromRoute] Guid orderId, [FromBody] PlaceOrderCommand command)

I think MVC defaults to FromBody semantics if you only specify a single object parameter and requires an explicit attribute if you include other parameters with attributes.

Always happy to help out if you need anything.

[mauroservienti]

So in theory you could get as near to controller action parameter behaviour.

Correct, that's the idea

I think MVC defaults to FromBody semantics if you only specify a single object parameter and requires an explicit attribute if you include other parameters with attributes.

That's tricky; for example, take a look at this Stack Overflow discussion.

[markphillips100]

Ah right, so the optional FromBody only applies when using ApiController attributes on controllers. Good catch.