ASP.Net WEB API Against WCF

In this article, we will try to understand the concept of the ASP.NET Web API along with examples of creating a WebAPI and consuming it step-by-step. This article is intended for an audience with a basic understanding of WCF and MVC.

So what are the points that we will be covering today?

What is ASP.NET WEBAPI
Why ASP.NET Web API when we already had WCF REST Services
Creating a sample application using Web API
When to use WCF and when Web API

What is ASP.NET Web API?

We know that HTTP is mainly used for serving webpages/images/PDFs. But then Microsoft had changed our idea of looking into this HTTP by making HTTP used for building the strong API that can reach a large number of clients, like browsers, mobile devices and so on in a more flexible way. As we have access to the internet so we access HTTP. Hence HTTP is found everywhere today. So making this HTTP a powerful tool for exposing services to the client is what is called the ASP.NET WEB API.

The ASP.NET WEBAPI is a platform for building HTTP services that can be used over the web, on the top of .Net framework. This framework mainly works on HTTP standard verbs like GET, POST, PUT, DELETE, OPTIONS, and HEAD and uses the REST architecture. Here request for data can be made using a Uniform Resource Interface (URI) that actually can understand these HTTP verbs.

Each method specified above has some specifications. The GET method should be used to get the resources from the server. Likewise the POST method should be used to post the resources to the server.

These resources can be any non-SOAP content like XML, JSON, TEXT, IMAGE and many more.

Wow isn't it? But all this can be done using WCF REST also.

Why ASP.NET Web API when we already had WCF REST Services

WCF is a powerful programming model for creating SOAP based services to support various protocols like Messaging queue, duplex communication, one way messaging, transaction based communication and so on by making small configuration changes. As you know, SOAP allows all settings required for any services in the message itself. Using WebHTTPBinding, WCF can support REST based services. So why was the WEB API brought into the market? The answer is:

As explained before, it supports HTTP, an application level protocol. That means indirectly it supports the HTTP standard verbs that define the action (GET, POST, PUT, DELETE and HEAD).
It provides strong support for URL routing using MVC style routing.
It contains message headers that are self-descriptive. It explains the ContentType of messages, cache information, Content Negotiation based on Accept headers for request and response serialization.
It supports non-SOAP output formats like JSON, XML, ATOM and also supports new input/output types
It can be self-hosted in non- Web Applications.
Also Unit Testing is made easy since it is similar to the MVC Architecture.

Let's create a simple example to explain the WEB API.

Here, in the WEB API we extend from the controller called ApiController for HTTP verbs. And for returning views (aspx, cshtml) we need to use the default MVC controller. In our sample we will create a service that returns customer details as a resource.

Note: Before understanding the WEBAPI, you need to have a basic knowledge of MVC Architecture.

1. To create a WEB API, you need a MVC Template. First of all create a new MVC web application and select the WEB API.

2. As you can see, as a default template we have a controller that extends from ApiController.

This is our API Controller in which we will be writing our Http Methods.

3. Routing

There is 1 more routing config that has been added to the App_Start folder, WebApiConfig.cs along with RouteConfig.cs. This Config file contains a similar Routing table that we usually see in MVC routing. But the only difference we find over here is the routingTemplate starts with api/{controller}/{id} and there is not an action specified. As I said before the WEBAPI mainly works on HTTP verbs which means if I have any action that starts with GET (for example: GetCustomer), it will consider it as a WEBAPI method. The same for the other methods also.

4. Adding a model: A model can be any class that represents the data in your application. The ASP.NET Web API can automatically serialize your model to JSON, XML, or some other format and then write the serialized data into the body of the HTTP response message. So I am creating a Customer Model over here.

public class Customer
{
[Key]
public int CustomerId { get; set; }
[Required(ErrorMessage = "Enter Customer Name")]
public string CustomerName { get; set; }
[Required(ErrorMessage = "Enter Customer Code")]
public string CustomerCode { get; set; }
[Required(ErrorMessage = "Enter Address")]
public string CustomerAddress { get; set; }
}

5. Adding a controller: In the Web API, a controller handles HTTP requests. Let's provide the controller name as CustomerController.

Note: This Controller should inherit the ApiController class instead of Controller class as in MVC.

In the Controller, I am adding the HTTP methods as shown below. I am not writing any database driven code, it will just get the list of Customers from the Cache object and perform an operation on it.

public class CustomerController : ApiController
{
public List<Customer> customers = new List<Customer>() {
new Customer{ CustomerId = 1, CustomerCode = "C01", CustomerName = "ABC", CustomerAddress = "Mumbai" }
,new Customer{ CustomerId = 2, CustomerCode = "C02", CustomerName = "DEF", CustomerAddress = "Delhi" }
,new Customer{ CustomerId = 3, CustomerCode = "C03", CustomerName = "XYZ", CustomerAddress = "New York" }
};
/*GET Method*/
public IEnumerable<Customer> Get()
{
if (System.Web.HttpContext.Current.Cache["custlist"] == null)
{
System.Web.HttpContext.Current.Cache["custlist"] = customers;
}
else
{
customers = System.Web.HttpContext.Current.Cache["custlist"] as List<Customer>;
}
return customers;
}
/*GET method with parameter*/
public Customer Get(int id)
{
if (System.Web.HttpContext.Current.Cache["custlist"] == null)
{
System.Web.HttpContext.Current.Cache["custlist"] = customers;
}
else
{
customers = System.Web.HttpContext.Current.Cache["custlist"] as List<Customer>;
}
return customers.Where(d => d.CustomerId == id).SingleOrDefault();
}
/*POST Method*/
public Customer Post(Customer cust)
{
if (System.Web.HttpContext.Current.Cache["custlist"] == null)
{
System.Web.HttpContext.Current.Cache["custlist"] = customers;
}
else
{
customers = System.Web.HttpContext.Current.Cache["custlist"] as List<Customer>;
}
if (cust.CustomerId == 0)
{
cust.CustomerId = customers.Max(t => t.CustomerId) + 1;
customers.Add(cust);
}
else
{
Customer c1 = customers.Find(c => c.CustomerId == cust.CustomerId);
customers.Remove(c1);
customers.Add(cust);
}
System.Web.HttpContext.Current.Cache["custlist"] = customers;
return cust;
}
/*PUT Method*/
public Customer Put(Customer cust)
{
var t = Get(cust.CustomerId);
if (t == null)
throw new Exception(string.Format("Task with id {0} not exists.", cust.CustomerId));
return t;
}
/*DELETE Method*/
public bool Delete(int id)
{
var c = Get(id);
if (c == null)
return false;
if (System.Web.HttpContext.Current.Cache["custlist"] == null)
{
System.Web.HttpContext.Current.Cache["custlist"] = customers;
}
else
{
customers = System.Web.HttpContext.Current.Cache["custlist"] as List<Customer>;
}
customers.Remove(c);
return true;
}
}

That's it! Our Web API is ready for action. Now as I told you before it is a resource oriented service, so each method will correspond to one or more URIs.

Controller Method	URI
Get	api/Customer/
Get(id)	api/Customer/id
Post	POST api/Customer/
Put	PUT api/Customer/
Delete	DELETE api/Customer/

6. Now let's consume this resources using jQuery. I have designed a simple UI that will have fields to capture Customer Details and the same list be shown below in the grid with edit and delete functionality.

Listing functionality

$('#btnlist').click(function () {
$.getJSON('/api/Customer', function (c) {
$('#result').html('');
var str = '';
str+="<table class='mGrid'>";
str+='<th>Customer Code</th><th>Customer Name</th><th>Address</th><th></th><th></th>';
$(c).each(function (i, item) {
str+='<tr>';
str+='<td>' + item.CustomerCode + '</td>';
str+='<td>' + item.CustomerName + '</td>';
str+='<td>' + item.CustomerAddress + '</td>';
str+='<td>' + '<input type="button" id="editbtn" value="Edit" onclick="fnEdit(' + item.CustomerId + ');"/></td>';
str+='<td>' + '<input type="button" id="delbtn" value="Delete" onclick="fnDelete(' + item.CustomerId + ');"/></td>';
str+='</tr>';
});
str+="</table>";
$('#result').html(str);
});
});

Save functionality

$('#btnsave').click(function () {
var CId = $('#CustomerId').val();
var CCode = $('#CustomerCode').val();
var CName = $('#CustomerName').val();
var CAddress = $('#CustomerAddress').val();
var C = { CustomerCode: CCode, CustomerName: CName, CustomerAddress: CAddress,CustomerID: CId };
$.post("@Url.Content("/api/Customer/")", C).done
(
function (msg) {
$('#btnlist').click();
alert("Updated Sucessfully");
$('input:not([type=button])').val('');
}
).fail(function (e) { alert(e.statusCode);});
});

Edit Functionality

function fnEdit(cid) {
var C = { CustomerId: cid };
$.ajax(
{
url: "@Url.Content("/api/Customer/")"
, type: "PUT"
, datatype: 'json'
, data: C
, success: function (msg) {
if (msg != null) {
$('#CustomerCode').val(msg.CustomerCode);
$('#CustomerName').val(msg.CustomerName);
$('#CustomerAddress').val(msg.CustomerAddress);
$('#CustomerId').val(msg.CustomerId);
}
}
});
}

Delete Functionality

As you can see above, I have passed the header as a parameter to the ajax method. Because the DELETE method was not being called by passing the type :DELETE. This is due to the browser or firewall.

How to overcome that

One thing we can do is the override the HTTP methods inside with other supported HTTP methods.
It means call the HTTP service with the POST method but when routing call the override with other methods, say DELETE as header as shown below.

X-HTTP-Method-Override:DELETE"

To do this you need to write one MethodOverrideHandler and register it in MessagingHandler:

Register this method

config.MessageHandlers.Add(new MethodOverrideHandler());

When to use WCF and when Web API

If you want to expose a service to the public and the same service you want to work on various protocols like Messaging Queue, TCP, Named Pipes or duplex communication go for WCF.
If you want to create a service that supports HTTP and SOAP-based messaging, go for WCF.
If you want to create a resource-oriented service over HTTP and use the full features of the HTTP protocol then go for the ASP.NET WEBAPI.
If you want to access services based on URI and get a non-SOAP response like XML or JSON then go for ASP.NET WEBAPI.
If you have an application developed in MVC and want to have a service to be exposed then go for the WEBAPI. Automated Testing of business logic will also be easy for services since controller is separated from the UI and Model.

Conclusion

The Web APIs, therefore, were intended to allow creating HTTP services that only use the standard HTTP concepts (URIs and verbs) and use more advanced HTTP features like request/response headers, caching information and so on. I hope you will like this article. Don't forget to share your comments whether it's good or bad. Sharing is valuable no matter what.

References

Tiny Happy Features #2 - ASP.NET Web API in Visual Studio 2012

6 Comments

Join the conversation! Your thoughts help the community grow.

Prerana Tiwari12y ago
Nice article..........
saditya kapoor12y ago
Nice Pradeep good work. thanks for sharing.
Sai Sherlekar12y ago
nice article pradeep.. thnks for sharing
Sukesh Marla12y ago
vERY nICE
Pradeep Shet12y ago
Thanks...
Anupam Singh12y ago
well described Pradeep. thank you for sharing.