Why does ApiController require explicit Http verbs on methods?

Question

I'm using ApiController. I struggle to understand why ApiControllers differ from Controllers in certain ways.

Take

public class QuestionCommentController : ApiController
{
    QuestionCommentCRUD crud = new QuestionCommentCRUD();

    // GET api/questioncomment/5
    [HttpGet]
    public string Read(int id)

I'm accustomed to Controller types which allow me to create method without specifying the legal verbs via Attributes:

public class QuestionCommentController : Controller
{
    QuestionCommentCRUD crud = new QuestionCommentCRUD();

    // GET questioncomment/5
    public string Read(int id)

In the latter case I can perform GET/POST without specifying HttpGetAttribute. I find this behavior confusing for a few reasons:

• There's now two HttpGet: System.Web.Http.HttpGet and System.Web.Mvc.HttpGet
• System.Web.Http.HttpGet is required, System.Web.Mvc.HttpGet is not required for GET requests
• ApiController requests require a unique route /api/controller...

Controller's allows me to fall into the pit of success. The newer ApiController requires hand holding.

I noticed the default template has a syntax that I don't understand:

    public void Post([FromBody]string value)
    {
    }

The verb is the method name along with some funky [FromBody] thing going on. Maybe this is why things are setup this way? What assumptions exist about the usage of ApiController that led to this design?

Answer 1

Your API controllers don't require verbs on the methods if you follow the built in convention. If you prefix your method names with the proper verb, Get, Post, etc. there's no need to decorate with the attribute.

In your case.

public string GetRead(int)

and a live example from a project I'm currently working on

[Authorize]
public HttpResponseMessage GetStoreList([FromUri]NamedViewModel model)

No decoration necessary, so System.Web.Http.HttpGet is not required.

You can do it the way you have listed above or the way I have it. WebApi is allowing you to do either REST or RPC style calls as you see fit. That's why you see the differences. The inclusion of support for RESTful style calls required additional work.

I will agree that the two separate HttpGet attributes is confusing, especially when both are included in a WebApi project out of the box. That bit me a few times when I accidentally included the wrong namespace.