none
How are Web API controllers different from regular MVC controllers?

 > 

    Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    I like Web API controllers in ASP.NET because I can create HTTP-based services that return JSON (since JSON is so easy for JavaScript to digest).

    What I don't understand is how this new tool differs from MVC3 controllers. I could do that in MVC3.

    Web API controllers can return XML or JSON on the fly which is *yawn* sort of nice, at least if I was writing views to be coupled to two different formats.

    I don't mind having to end the name of my controllers now with the word "controller", but -like hungarian notation- this doesn't seem to add a lot of value either (reminds me of the guy in the Far Side comic who painted "CAT" on his cat and "HOUSE" on his house ... I don't hold it against him, but I'm not having trouble recalling that my house is a house).

    The articles I've read about ASP.NET Web API seem very top-down, cerebral even. They detail a meta-narrative of SOAP enclaves yielding to HTTP. If that's true, how does Web API support HTTP more than the MVC3 controllers? In what way does a developer notice more HTTP-ey things going on?

    I'm glad the ASP.NET team understands the selling features of MVC3, but it seems like they kind of re-invented the wheel on this one.

    Tuesday, July 02, 2013 12:51 PM
    |
    |

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

      Web Api Controller differ from MVC controller. Web Api Controller derives from ApiController class and MVC controller derives from Controller class. Both are served for different purposes. The web controller action returns data and not views but controller action returns views.

    Balaji -Please click mark as answer if my reply solves your problem.

    Thursday, July 04, 2013 10:00 AM
    |
    |
  • Question
    Sign in to vote
    0
    Sign in to vote

    IMO what you have is a pattern called MVC. The asp.net MVC framework implements MVC in order to originally provide HTML with the extension of providing JSON.

    WebAPI is an evolution of WCF which many felt was overcomplicated when we "just" needed a simple API for http clients. What MS have done is reuse the MVC pattern to implement WebAPI. This means ASP.MVC and WebAPI share a lot of the same patterns and implementations, e.g. routing. This is good news because the move from ASP.MVC to WebAPI is simple. However, it's bad news because they look almost identical and is therefore confusing.

    For me you've touched on the key difference, that of content negotiation. ASP.MVC can support that by adding equivalent controllers or by subtly duplicating the API. But this is all extra work and extra danger wrt changes. WebAPI's content negotiation allows you to ask in one format and return in another. This is good news if you are writing a public API. If you're just writing for a very specific client, i.e. one you are in total control of, then perhaps it's just not going to be important to you. There are other little helpers too, such as the basic template laying out a design that tries to push you towards REST by using the correct HTTP verbs. But overall I would say content neg' is the big advantage.

    http://pauliom.wordpress.com

    Sunday, July 07, 2013 8:10 AM
    |
    |