Before we delve into the building blocks and design principles behind ASP.NET Web API, it is important to understand that ASP.NET Web API is an evolution of the existing continuous Microsoft efforts to enable support for HTTP Services. A timeline of events that describe this evolution are outlined next.

Windows Communication Foundation (WCF) (https://msdn.microsoft.com/en-us/library/ms731082%28v=vs.110%29.aspx) was launched with .NET 3.0 for SOAP-based services; the primary aim was to abstract the transport layer and enable support for the WS-* protocol. No HTTP features were enabled except HTTP POST for requests

In NET 3.5, WebHttpBinding (https://msdn.microsoft.com/en-us/library/system.servicemodel.webhttpbinding%28v=vs.110%29.aspx) was introduced in WCF with the intent to support services that were not based on SOAP. It allowed systems to configure endpoints for WCF services that are exposed through HTTP requests instead of SOAP messages. The implementation was very basic and...

As described in the previous section, ASP.NET Web API is built on top of existing frameworks and technologies. Web API leverages features from ASP.NET MVC, the core ASP.NET framework, and the .NET framework to reduce the overall learning curve for developers and at the same time provides abstraction to make programming easier. The following figure highlights the key features that make up the ASP.NET Web API framework.

Now that we understand the intent behind ASP.NET Web API, let's discuss some design principles on which ASP.NET Web API is based:

As mentioned before, ASP.NET Web API enables customers to easily and rapidly develop HTTP-based services that can result in new business opportunities or improved customer satisfaction. Some of these scenarios are described here:

Let's talk about some of the internal workings of ASP.NET Web API and how a request is received and a corresponding response generated.

The routing and dispatching stage primarily involves the execution of a series of message handlers, which process the incoming request and then delegate them to the next message handler for processing. In earlier versions of ASP.NET Web API, we could only configure message handlers globally per application. All the message handlers were added to the HttpConfiguration.MessageHandlers collection and were executed for each request. The global configuration was enabled using the Register method in the WebApiConfig.cs file, which gets added when creating a new ASP.NET Web API project. We talk more about the WebApiConfig and Register method in the Creating our first ASP.NET Web API section. The following snippet show a sample Register method definition:

public static void Register(HttpConfiguration config)
{

    config.Routes.MapHttpRoute(
       name: "DefaultApi",
       routeTemplate: "api/{controller}/{id}",
       defaults: new { id = RouteParameter...

In this section, we will start building our Web API, covering the necessary environment required for creating a Web API. We will also discuss our problem scenario, and then create a Web API from scratch. We will then delve into the details of Microsoft Azure websites and deploy our first Web API in Microsoft Azure.

Now that we have a Web API created, we will look at options to validate our Web API functionality. Testing is a crucial stage in the creation of Web API development and publishing. There are a couple of different ways of doing this. We can just test it by requesting the URL in a browser or write code and leverage the System.Net.HttpClient type. This section discusses both of these approaches.

In the previous section, we built and tested our Web API. Now, we discuss how to use Visual Studio Online and Git for source control management. Note that this section assumes that we have a Git repository created and available. It does not give a walkthrough of setting up a Git repository within VSO.

We will now commit the change to Visual Studio Online. Visual Studio 2013 provides a rich integration with Git so we can commit the changes without opening the Git command prompt:

Microsoft Azure Websites is a Platform as a Service (PaaS) offering from Microsoft, which allows publishing web apps in Azure. The key focus when building Microsoft websites is to enable a true enterprise-ready PaaS service by allowing rapid deployment, better manageability, global scale at high throughput, and support for multiple platforms. The development of Azure Websites started about 3 years ago under the internal project name Antares with the primary intent to create a cheap and scalable web hosting framework for Microsoft Azure. The main target was shared and cross-platform hosting scenarios. The first preview release for Azure Websites came out in June 2012 and went General Availability (GA) in mid-2013.

In the previous section, we used Visual Studio tools to deploy our Web API in Microsoft Azure Websites. The Visual Studio deployment option works well for one-off deployments or small development projects. However, in real-world scenarios, customers prefer integrating builds with automated deployments. Azure Websites provides continuous deployment from source code control and repository tools such as BitBucket, CodePlex, Dropbox, Git, GitHub, Mercurial, and Team Foundation Server. We can, in fact, do a Git deployment from a local machine!

For the purpose of this sample, we use VSO and Git as our repository. Let's take a look at how we can configure Visual Studio Online for our Continuous Deployments (CD):

This chapter provided an overview of the what, why, and how of an ASP.NET Web API. ASP.NET Web API is a next generation service that enables support for a first-class modern HTTP programming model. It provides abundant support for formats and content negotiation, and request validation.

We talked about the foundational elements of a Web API. We then discussed its usage scenarios and components, and also discussed the classes that make up the API. We went through the request-response pipeline and walked through the message lifecycle of a request. We then created our first simple Web API for a simplified customer scenario and walked through its development, testing, and deployment using Azure Websites. In the next chapter, we will look into advanced capabilities of ASP.NET Web API, and see how these capabilities can be used to customize different aspects of the ASP.NET Web API request-response pipeline.