To me personally the most important improvement is the integration of the WCF Web API into the ASP.NET Stack.
One of the main reason for merging both has been the question "why two frameworks from Microsoft which allow us to create ReSTful APIs?"
Thus, the ASP.NET MVC developers now get the goodies from the WCF Web API.
Let's take a look at how we do things now.
The most important change is the implementation of our own APIs themselfes:
Until now, we did it this way using WCF Web API::
Using ASP.NET Web API it looks like this:
As you can see, you're implementing now a Controller also for APIs. But it does not derive from Controller as MVC Controllers do and there's no common base class at all.
When looking at our code, you may ask: how does Web API know, which HTTP Methods should be mapped to which class methods?
ASP.NET Web API now uses Convention over Configuration already known from ASP.NET MVC, thus naming of the class method declares the HTTP method being used.
And by the way: Convention over Configuration also takes effect at the controllers: Controllers have to be inside the Controllers folder known from MVC.
Convention over Configuration...but
...there's still a little piece of confiugration left. Let's head over to the Global.asax.cs. That's the place where ASP.NET Web API is (still) configured.
The only mandatory option that needs always to be configured, is the assignment of a route inside the route tables to our API controllers.
Here is another improvement: ASP.NET Web API now uses ASP.NET MVC Routing. But be careful: Route definitions don't use MapRoute but MapHttpRoute instead:
The difference between default MVC route and the default Web API Route is that the action is not contained in our URIs (that's were the convention comes in).
Thus, our API is available here:
GET /customers/id, PUT, POST etc. work analogous.
If you want to implement more than one GET method on your web api class, you simply activate the action in you route definition:
Dependency Injection still works, of course - shown here using LightCore.
To give and receive...
Certainly, the improvements did not only come from WCF Web API to ASP.NET Web API, but also from ASP.NET MVC, e.g. Model Binding and Validation.
To use Validation you can use the already known Annotations like [Required] etc.:
To get it working, we need an ActionFilter:
The ActionFilter validates the incoming model (e..g. from POST) and creates a JSON object if there were validation errors and sends them back to the client with a HTTP 400 (Bad request) status code.
At the client side we're utilizing the response using jQuery AJAX POST:
Of course, on the client side it is necessary to include jQuery unobstrusive Validation Scripts and setting the HTML attributes:
ASP.NET Forms authentication now also is supported out of the box, but this will be part of another blog post.
Besides the well known IIS Hosting it is now also possible to self host Web API inside your own process (which is not new for WCF but MVC):
In order to get self hosting working, System.Web.Http.SelfHost needs to be referenced.
That's it for now to give you a short overview.