If you have worked with the .NET Framework for any amount of time, you must have encountered the term WCF (Windows Communication Foundation), the one-stop framework for all service development needs in the .NET Framework.
Why the new framework of ASP.NET Web API then? The short answer is that 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,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, ASP.NET Web API is not supposed to replace WCF anymore.
It is important to understand the coexistence of WCF and ASP.NET Web API. WCF has been around for a while, and ASP.NET Web API is a new kid on the block, but that does not mean WCF is meant to be replaced by ASP.NET Web API. Both WCF and ASP.NET Web API have their own place in the big picture.
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.
When it talks about to 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 Java Script 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 Authorthe 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
{
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. Features of MVC that developers like, such as binding and testability, which are typically achieved 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 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. 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 ASP.NET Web API as the back end really shines and brings the most value:
• Rich-client web applications: 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: ASP.NET Web API can be a back end for native Applications (Which Built for a particular 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.
0 comments :
Post a Comment