I'm a huge fan of coding against interfaces. In the WCF world, this highly emphasized on every service. However, I'm getting deeper into ASP.NET Web Api, as an extension of MVC 4, I was curious to see if there was some typical reasoning to have your controller implementations inherit from an interface.
I know the default settings for ASP.NET Web Api look something like this
public class TestsController : ApiController
{
public IEnumerable<string> Get()
{
var testValues = new List<string>
{
"Something",
"Welcome to the top of the world"
};
return testValues;
}
}
As opposed to this WITH a cooresponding interface (or interfaces).
public class TestsController : ApiController, ITestsController
{
public IEnumerable<string> Get()
{
var testValues = new List<string>
{
"Something",
"Welcome to the top of the world"
};
return testValues;
}
}
I think there is no value in using an interface like that for a controller. WCF relies a lot on interfaces because it's a common thing for SOAP services, and it is something used for generating the contracts in WSDL. However, an HTTP Web API does not have that kind of contract, and it is typically a bad practice to have it. Also, interfaces are common when you need to use dependency injection and unit testing because they allow you to easily fake dependencies. However, I don't think you would inject a controller as dependency into another class, so it does not make sense there too.