History Behind ASP.NET WEB API

ASP.NET WEB API: 
It is a framework for building and consuming HTTP services that can reach a broad range of clients including browsers and mobile devices. It’s also a great platform for building RESTful services. ASP.NET Web API takes the best features from WCF Web API and merges them with the best features from MVC.
Even before touching code, we need to know why WEB API?

It started with WCF
WCF is a revolutionary change that happened in Service Oriented Approach.
It is a strong programing model for writing services, which itself will take care of Instance Management, Throttling, Concurrency, Threading, Transactions, Fault Tolerance, Security, and so on.It is is designed for cross protocol compatibility.

Coming to HTTP, although SOAP is wide spread and supported on maservices.ny platforms, it is not the only way to go when creating services. There is also a need to also support non-SOAP services, especially over HTTP, where you can harness the power of the HTTP protocol to create HTTP services: services that are activated by simple GET requests, or by passing plain XML over POST, and respond with non-SOAP content such as plain XML, a JSON string, or any other content that can be used by the consumer. Support for non-SOAP services was very much needed in WCF back then, mostly because some clients, such as web browsers, were not that suitable to handle SOAP messages

Here comes WCF Restful services.

The WCF Web Http programming model was first introduced as part of the .NET framework 3.5 SP1 for building non-SOAP http services that might follow or not the different REST architectural constraint. This new model brought to the scene some new capabilities for WCF by adding new attributes in the service model ([WebGet] and [WebInvoke]) for routing messages to service operations through URIs and Http methods.
WebOperationContext is a static object for getting access and controlling different http header and messages, and finally a new binding WebHttpBinding for handling some underline details related to the http protocol.
The support for doing TDD at this point is somehow limited fore the fact that services rely on the static context class for getting and setting http headers, making very difficult to initialize that one in a test or mock it for setting some expectations.
There out put of these services support only XML or JSon format. For any other format, you might need to extend the default WebContentTypeMapper class

Addressing these problems, WCF Data services evolved.

WCF Data Services, formerly called ADO.NET Data Services, was introduced in the .NET stack as way of making any IQueryable data source public to the world through a REST API. WCF Data Service sits on top of the WCF Web programming model, and therefore is a regular WCF service.
These services exposes metadata for the consumers, and also adds some restrictions for the URIs and the types that can be exposed in the service. All these features and restrictions have been documented and published as a separate specification known as OData.

After all the enhancements, its is still a WCF service, which needs lot of configurations, URI Templates, Contracts and endpoints. Service implementation and consumption is not simple.

Here comes ASP.NET WEB API.
ASP.NET Web API includes support for the following features:

• Modern HTTP programming model: Directly access and manipulate HTTP requests and responses in your Web APIs using a new, strongly typed HTTP object model. The same programming model and HTTP pipeline is symmetrically available on the client through the new HttpClient type.
• Full support for routes: Web APIs now support the full set of route capabilities that have always been a part of the Web stack, including route parameters and constraints. Additionally, mapping to actions has full support for conventions, so you no longer need to apply attributes such as [HttpPost] to your classes and methods.
• Content negotiation: The client and server can work together to determine the right format for data being returned from an API. We provide default support for XML, JSON, and Form URL-encoded formats, and you can extend this support by adding your own formatters, or even replace the default content negotiation strategy. Model binding and validation: Model binders provide an easy way to extract data from various parts of an HTTP request and convert those message parts into .NET objects which can be used by the Web API actions.
• Filters: Web APIs now supports filters, including well-known filters such as the [Authorize] attribute. You can author and plug in your own filters for actions, authorization and exception handling.
• Query composition: By simply returning IQueryable<t>, your Web API will support querying via the OData URL conventions.
• Improved testability of HTTP details: Rather than setting HTTP details in static context objects, Web API actions can now work with instances of HttpRequestMessage and HttpResponseMessage. Generic versions of these objects also exist to let you work with your custom types in addition to the HTTP types.
• Improved Inversion of Control (IoC) via DependencyResolver: Web API now uses the service locator pattern implemented by MVC’s dependency resolver to obtain instances for many different facilities.
• Code-based configuration: Web API configuration is accomplished solely through code, leaving your config files clean.
• Self-host: Web APIs can be hosted in your own process in addition to IIS while still using the full power of routes and other features of Web API.

 It is assumed that in future, Entity Framework will expose the functionality as a WEB API, so that all the operations on entities can be done in a RESTful manner.

We will see the basics of a WEB API Programing in next posts . . .

Is it helpful for you? Kindly let me know your comments / Questions.