Attribute routes need to be inherited. Every web api I've written I've started with a base class that handled basic crud operations with a generic service, something like...
public class ProductController : RestController<Product> {}
where RestController<T> had an IGenericService<T> to handle all the basic RESTful actions. For simple controllers (which make up a large portion of controllers), this would suffice. For anything that needed more, I could simply override or add to what was in the base. This is the benefit of object oriented languages. We don't have to repeat ourselves.
That's why I was very surprised to to discover AttributeRouting in WebApi2 doesn't allow inheritance, by design of all things. I can't think of a single good reason why this would be done inside an object oriented language.
The implementation should be simple. Take a look at what AttributeRouting.WebApi did over two years ago. - https://github.com/mccalltd/AttributeRouting/wiki/Inherit-Routes-from-Actions-in-Base-Controllers. You should have done so before you started working.
Please correct this design mistake. Thank you for listening to your community.
Comments: @timhardy, The reason we chose not to implement inheritance by default, is that the semantics of derivation and routing is not the same, where routing is additive by nature and inheritance is overriding. This might work for a micro or a very targeted solution, but we felt we are not willing to deal with the fallout of enabling this by default. And we still feel the same way. To be clear we are well aware of Tim's work (in fact we worked closely with him throughout the development of this feature), and made this explicit choice, and we currently plan to stick with it. However we are aware of this need, and we are actively looking at a way to easily enable the scenario (and a bunch of other scenarios). The following issue tracks it: https://aspnetwebstack.codeplex.com/workitem/1464 Feel free to vote on it. if you believe we closed a bug in error, you can just reactivate it rather than opening another one. (It still doesn't guarantee we take it thought :)) I hope the solution above will satisfy your needs, we will of course provide How-To samples with it.
public class ProductController : RestController<Product> {}
where RestController<T> had an IGenericService<T> to handle all the basic RESTful actions. For simple controllers (which make up a large portion of controllers), this would suffice. For anything that needed more, I could simply override or add to what was in the base. This is the benefit of object oriented languages. We don't have to repeat ourselves.
That's why I was very surprised to to discover AttributeRouting in WebApi2 doesn't allow inheritance, by design of all things. I can't think of a single good reason why this would be done inside an object oriented language.
The implementation should be simple. Take a look at what AttributeRouting.WebApi did over two years ago. - https://github.com/mccalltd/AttributeRouting/wiki/Inherit-Routes-from-Actions-in-Base-Controllers. You should have done so before you started working.
Please correct this design mistake. Thank you for listening to your community.
Comments: @timhardy, The reason we chose not to implement inheritance by default, is that the semantics of derivation and routing is not the same, where routing is additive by nature and inheritance is overriding. This might work for a micro or a very targeted solution, but we felt we are not willing to deal with the fallout of enabling this by default. And we still feel the same way. To be clear we are well aware of Tim's work (in fact we worked closely with him throughout the development of this feature), and made this explicit choice, and we currently plan to stick with it. However we are aware of this need, and we are actively looking at a way to easily enable the scenario (and a bunch of other scenarios). The following issue tracks it: https://aspnetwebstack.codeplex.com/workitem/1464 Feel free to vote on it. if you believe we closed a bug in error, you can just reactivate it rather than opening another one. (It still doesn't guarantee we take it thought :)) I hope the solution above will satisfy your needs, we will of course provide How-To samples with it.