If you have worked with the .NET Framework for any amount of time then you must have encountered the Windows Communication Foundation (WCF), the one-stop framework for all service development needs in the .NET Framework.
Why the new framework of ASP.NET Web API? The short answer is that the ASP.NET API is designed and built from the ground up with only one thing in mind, HTTP, whereas WCF was designed primarily with SOAP and WS-* (TCP, NetTCP and MSMQ) in mind, and Representational State Transfer (REST) was retrofitted through the WCF REST Starter Kit. The programming model of ASP.NET Web API resembles ASP.NET MVC in being simple, instead of requiring you to define interfaces, create implementation classes, and decorate them with several attributes. However, the ASP.NET Web API is not supposed to replace WCF anymore.
It is important to understand the coexistence of WCF and the ASP.NET Web API. WCF has been around for a while, and the ASP.NET Web API is a new kid on the block, but that does not mean WCF is meant to be replaced by the ASP.NET Web API. Both WCF and the ASP.NET Web API have their own place in the big picture.
The ASP.NET Web API is lightweight but cannot match the power and flexibility of WCF. If you have your service using HTTP as the transport and if you want to move over to some other transport, say TCP, NetTCP, MSMQ or even support multiple transport mechanisms, WCF will be a better choice.
For the client base, not all platforms support SOAP and WS-*. ASP.NET Web API–powered HTTP services can reach a broad range of clients including mobile devices.
Responses can be formatted into the JavaScript Object Notation (JSON) and Extensible Markup Language (XML) formats.
Let’s try to understand the differences in programming models by looking at a simple example: an author service to get an author of an organization, based on the authorID. WCF code (see Listing 1-1) is voluminous, whereas ASP.NET Web API code (see Listing 1-2) is terse and gets the job done.
Listing 1-1. Getting an Author the WCF Way
[ServiceContract]
public interface IAuthorService
{
[OperationContract]
AuthorGetAuthor (string id);
}
public class Author: IAuthorService
{
public Author GetAuthor (string id)
{
return new Author () { Id = id, Name = "Sachin Kalia" };
}
}
[DataContract]
public class Author
{
[DataMember]
public int Id { get; set; }
[DataMember]
public string Name { get; set; }
}
A Basic Web API
Listing 1-2. Getting an Author the ASP.NET Web API Way
public class AuthorController : ApiController // Inherit ApiController for WebApi as Controller class in MVC apps
{
public AuthorGet(string id)
{
return new Author () { Id = id, Name = "Sachin Kalia " };
}
}
A couple of things are worth mentioning here: First, the web API is exactly the same as a normal MVC controller except that the base class is ApiController. The features of MVC that developers like, such as binding and testability, that are typically done through injecting a repository, are all applicable to a web API as well.
If you are experienced with ASP.NET MVC, you may be wondering how different a web API is; after all, the MVC controller’s action method can also return JsonResult. With JsonResult action methods, a verb is added to the URI (for example, http://server/authorByID/get/1234), thereby making it look more like a RPC style than REST. Actions such as GET, POST, PUT, and DELETE are to be accomplished through HTTP methods rather than through anything in the URI or query string. The ASP.NET Web API also has far superior features, such as content negotiation. ASP.NET MVC’s support for JsonResult is only from the perspective of supporting AJAX calls from the JavaScript clients and is not comparable to ASP.NET Web API, a framework dedicated to building HTTP services.
The following are the scenarios where the ASP.NET Web API as the back end that really shines and brings the most value:
- Rich-client web applications: the ASP.NET Web API will be a good fit for rich-client web applications that heavily use AJAX to get to a business or data tier. The client application can be anything capable of understanding HTTP.
- Native mobile and non-mobile applications: the ASP.NET Web API can be a back end for native applications (built for a specific platform) running on mobile devices where SOAP is not supported because HTTP is a common factor in all the platforms. Also, native applications running on platforms other than Windows can use ASP.NET Web API as the back end.
- Platform for Internet of Things (IOT): IOT devices with Ethernet controllers or a Global System for Mobile Communications (GSM) modem, for example, can speak to ASP.NET Web API services through HTTP. A platform built on .NET can receive the data and do business. Not just IOT devices, but other HTTP-capable devices such as radio frequency ID (RFID) readers can communicate with ASP.NET Web API.