Tag Archives: ASP.NET WebAPI

Microsoft ASP.NET WebAPI

Introductory demo on ASP.NET WebAPI

Welcome back, this is the second article in the series of articles on the ground breaking Microsoft REST based SOA technology framework, ASP.NET Web API.  I am going to show you some hands on demo on Implementing ASP.NET WebAPI using Microsoft Visual Studio 2012.

My previous article in this series on Introduction to ASP.NET WebAPI can be found in this link: https://alagesann.com/2012/10/31/a-detailed-introduction-to-asp-net-web-api/

If you have knowledge on ASP.NET MVC already, you probably know the most part of implementing a WebAPI because ASP.NET Web API structured, Implemented and routed almost like an ASP.NET MVC application, though there are some significant differences which we will explore shortly. So I assume here that you have atleast a little knowledge on the ASP.NET MVC  technology.

I am using Visual Studio 2012 ultimate for this demo.

You can create a simple Web API project just in 2 steps:

  1.  Create a new project by using ASP.NET MVC 4 Web Application project template.

Give a name for the project; I am using the name as “BookStore” and choose a location to store your project. Click OK.

2.  In the following window, choose the Web API to make the project ready for implementing web api. You can choose any template in order to build a web api project, but I am using Web API template so it will give me a sample Api controller automatically. Leave Razor view engine selected and since I am not using a unit test for now for simplicity, leave that check box unchecked.

Now you are landed on the visual studio working window where you can see an initial window like this:

Important points to note here with respect to WebApi are:

  1. System.Web.Http dll is referenced automatically for you to build the web Api functionality.
  2. WebApi is installed by default as a nuget package for the projects you create in VS 2012. You can check that by going through “Manage Nuget  Packages” option from the  context window that appears when you right click on the project. “ Microsoft ASP.NET WebApi “ is installed as shown in the following Nuget Packages window: 
  3. A Default WebApi controller named “ValuesController” is added to the “Controllers” folder and this controller is extended from “ApiController” (will explore why is that shortly). Most importantly this controller has methods “Get, Get by Id, Post, Put and Delete” implemented.
  4. A WebApi route configuration file “WebApiConfig.cs” is added to the “App_Start” folder.

Okay, enough of analyzing some basic setups, lets browse the project and try to navigate to the default Apis created by Visual studio.

I am using google chrome, so let’s use it and play with the urls. When I try the url: /Values/Get/
to invoke the “Get” action of the ValuesController, it returns a 404 error. It should supposed to work as this is how it’s been working in ASP.NET MVC, but now it disappoints.
So let’s check what is there in the routing configuration for this WebApi project. Routing is defined in the WebApiConfig.cs as:

config.Routes.MapHttpRoute(
name: “DefaultApi”,
routeTemplate: “api/{controller}/{id}”,
defaults: new { id = RouteParameter.Optional }
);

So it turns out that, WebApi slightly works different from ASP.NET WebApi from routing perspective. WebApi routing has the word “api” in the route before the controller name. So the url must be

/api/Values/

Also note from the route template that there is no action name given right after the controller name. So How the appropriate action is going to be invoked when we hit the url. That’s an another aspect that ASP.NET MVC routing different from WebApi.

Http verbs like Get, Post, Put and Delete that are used to invoke the url are directly mapped to the   controller actions.

So I have to hit the url “/api/Values” it’s going to invoke the Get action from the ValuesController because it’s the “Get” http verb that’s used internally by the browser when I hit the url and I see the result as follows:

Cool, our Api now worked and it returned the response in the form of xml. But, wait. We just return the array of strings from the Get action and how it returns them as xml? It’s all the magic of Content-negotiation feature of WebApi framework.

WebApi supports many content forms starting from XML, JSON to ATOM and best of all it has the capability to be extended programmatically.

Okay, XML is fine. Now, how to retrieve the values in the form of JSON? This needs a little more capability on invoking the urls than the browser itself. So I am going to use Fiddler tool for that which you can download and install from the url:  http://www.fiddler2.com/fiddler2/version.asp and there are lot of videos and information on the fiddler for information on how to use it. So let’s directly use fiddler and get the JSON representation of the response.

My request header looks like this:

Host: localhost:8425
User-Agent: Fiddler
Content-Type: application/json; charset=utf-8

And hit Execute.

we get the response as:

Note the Json response of the response.

Summary:

We explored how to create a sample ASP.NET WebAPI project and its structure and routing mechanisms. We also tried to execute the apis using browser and fiddler. In the next article, we will explore how to implement a real service project, BookStore Service, using ASP.NET Web Api.

A detailed Introduction to ASP.NET Web API

This is a series of article on the Microsoft new framework called ASP.NET Web API which is released as part of the ASP.NET MVC 4.  ASP.NET Web API is the Microsoft’s recent solid answer for the HTTP oriented protocol services, in other words, REST services. Microsoft defines it as ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.

HTTP oriented RESTful services

HTTP oriented RESTful services are services that make use of HTTP verbs for its CRUD functionalities. HTTP GET verb for read/retrieve functionality, POST verb for Creation, PUT verb for updation, DELETE verb for removal.

For Example, if you are creating an online Bookstore application. You will use:

  1. HTTP GET verb for retrieving all customer details of the book store or detail of a particular customer.
  2. HTTP POST verb for creating any new customer when he/she signs up for your online book store.
  3. HTTP PUT verb for updating existing customer information like name, emailed, address or his/her subscription plan change.
  4. HTTP DELETE verb to remove the customer from the book store customer list when he/she terminates the subscription.  You can either remove the customer permanently or just put some flags and mark the customer as removed without removing his/her entire account from the application, well, that is internal detail as per the application requirements.

HTTP protocol oriented services have been in use for a few years already and is been a trendy way to implement web services (I mean services that run on the web, not the classic Web Services specifically as there is a major difference between HTTP service and classic Web Service). But really a great push towards HTTP services raised when hand-held devices and portable devices like smartphone, tablet evolved to a great extent as it used a rich internet applications with rich user interfaces.

The main driving forces of HTTP oriented services are:

  1. Hand-held portable devices like smart phones and tablets, these are the revolutionary devices that brought a whole new computing trend these days by brining lots and lots of apps with great user interface that needed huge dynamic data from its server.
  2. Browser based applications, applications like games, weather apps, personal apps etc., that run as embedded apps on the browser with rich user interface
  3. RIA applications/SPA (Single Page Applications) on the web needed dynamic data so frequently than plain html from its server and that data is rendered on the page using client technologies like JQuery, Knockout etc.
  4. Windows 8 brought a whole new trend of bringing desktop apps that run on the windows desktop like tablet apps. Those apps send/receive data over the net and those apps can be Microsoft’s own apps or third party apps installed from Microsoft store.

 ASP.NET Web APIs are different/better from classic Web Service and WCF:

Though these two frameworks can be used to develop services to support heterogeneous devices and platforms, their main differences are in their communication protocols. Classic Web Service uses SOAP and ASP.NET Web API uses HTTP as their respective communication protocol under the hood.

Diagram 1:  Heterogeneous devices possibly with various OS and applications communicating with SOAP, A classic Web Service scenario. 

Diagram 1:  Heterogeneous devices possibly with various OS and applications communicating with HTTP protocol, A ASP.NET WebAPI scenario. 

Advantages of ASP.NET Web API that uses Http protocol are:

  1. HTTP messages can be cached, firewall friendly and lightweight.
  2. They can be encrypted and can be processed by the processor in mobile devices.
  3.  Most of the devices in the world have capability to send and receive HTTP messages. So major reach.
  4. ASP.NET WebAPI provides many features like content negotiation and URI routing out of the box whereas in WCF you got to implement them using some plumbing.
  5. Full support for ASP.NET routing and filters
  6. Strong support of variety of output formats like JSON, XML and ATOM.
  7. Easy to unit test and provides self-hosting support.

Comparing ASP.NET WebAPI and Webforms and MVC:

  1. WebApi is designed especially to meet the current trend  of rich clients/applications that are running on web browser that are developed using client technologies like Jquery, knockout etc are consuming lightweight services over http protocol. In such cases webserver’s main role is not just about serving some html content but it’s really about accepting data and returning data in different format. You might have clients that are not just browser, it can be a mobile devices.
  2. But Webforms or MVC are mainly for consuming html. It can do other things like webapi, but for that you got to do a lot of plumbing work to make it happen. In other words, MVC is page/html oriented but webapi is API oriented.

Summary:

ASP.NET Web API is definitely a strong framework for building RESTful services compare to other existing framework like ASP.NET MVC and WCF. I strongly recommend anyone planning to use this technology for their service implementation that are targeting to global reach.

Let’s dive in some coding implementation of ASP.NET Web API in the next article of this series.

Next article in this series is here :

https://alagesann.com/2012/11/03/introductory-demo-on-asp-net-webapi/

Thanks for reading.