Introduction
WebApi 2 is the latest release from Microsoft ASP.NET family. It helps you to build robust and full-fledged RESTFUL web-services. It takes away all the heavy weight-lifting that you normally do with WCF services.
Let’s get a quick idea of what this is about.
Background
This is the first article in the upcoming series. This only explains what is WebApi and what advantages it has over its precursors. I plan to explain the coding and security aspects in the second and third series respectively.
Let's Get Some Idea
Before we start exploring more, below are some scenarios.
Scenario 1: John Wants to Get a List of All Employees in His Organization (Which Of Course is Maintained Internally)
Case 1: When there is a WCF service (developed already for intranet use)
- He looks up the service and finds WSDL for the same.
- Develop a client that consumes the service.
- Looks for the method which gives him the list of all employees.
- Creates a client object and calls the particular SOAP method.
- He can then access the list.
Case 2: When there is a WebApi service developed already for intranet use)
- He opens his browser and types “http://{serviceURL}/getEmployeeList/” and gets the list.
Wow, that was easy. Be it mobile, tablet, laptop or desktop with multiple OS, all can consume a WebApi RESTful service with great ease.
Scenario 2: Ever Wondered Why Mobile Applications Are a Little Quicker than Browsers?
Consider a mobile recharge Android application. All the data it needs is, what is the mobile number to recharge, the amount to be recharged & credit card information.
Case 1: Using traditional browsers
For a particular page, the browser needs to get the required Images, CSS (style sheets), JavaScript libraries, HTML from the server for each and every request. However optimized the webpage is, there are some additional overheads associated with every request that is made.
Case 2: Using Mobile app + RESTful services
The user needs to download a mobile app (for one time). Subsequent data are fetched using a RESTful service. The data consumption is usually in some KBs thus saving a lot of data and are a lot quicker.
History of WebApi
Before the advent of WebApi, WCF was used for creating RESTFUL services in the .NET world. Though being used extensively, the problem with WCF was its extensive configuration and lack of full HTTP service.
All RESTful calls were needed to be POST (though you only want to do a GET request).
The following diagram shows this in full detail.
Is This the End of WCF?
But wait, does that mean the WCF is no more of use?
The answer is a big No. Both have their own advantages and disadvantages.
When you want a lightweight service that is truly HTTP and REST based, you can definitely go for WebApi. The below table explains this in more detail.
| WebApi
| WCF
|
| Lightweight and robust.
| With SOAP definitions, comparatively a heavyweight solution.
|
| Its definition is more of an architectural style than a fixed protocol.
| It is a protocol and has a particular standard.
|
| Truly RESTful and a full blown HTTP service.
| Although supports RESTful architecture it is not fully HTTP friendly. It is intentionally geared to support only POST calls.
|
| No hefty configurations.
| Lots of configuration stuff.
|
| Fully platform independent. Develop once and consume anywhere in ease. Be it be tablet, mobile or Desktop with different OS. No problem. Powered and supported by HTTP architecture.
| Though claimed as platform independent, there is an underlying difficulty during consumption of the service. The SOAP Client tool is different for different platforms.
|
| More suitable for intranet apps. Internet facing API’s can use ASP.NET Identity or traditional ASP.NET membership.
| More suitable for internet due to a wide array of tighter security features with WS*- security standards.
|
| Learning curve is comparatively easy.
| Comparatively tougher because of a variety of configuration stuff.
|
| Open source & ships as a part of .NET
| Ships with the Microsoft .NET
|
| WebAPI Restful services are easy to scale horizontally since they are truly stateless
| WCF Services are difficult to scale horizontally as most of them tend to be stateful.
|
Tools for Learning Web API
What should you know before experimenting with WebApi?
- Familiarity with HTTP protocol and REST architecture.
- HTTP Response Codes. E.g. HTTP 200 means “Ok” while HTTP 400 means a “Bad request”. The exhaustive list can be found here.
- Bit of dependency injection, if you want some to develop some quality code.
- The ASP.NET WebApi site found here
Here is some WebApi code, if you need a peek into it.
public IHttpActionResult GetEmployees()
{
var employeesList = repository.GetAllEmployees();
return Ok(employeesList);
}
This particular code uses repository pattern (for fetching data from the database) and returns a status code (HTTP 200) on successful retrieval.
I will explain much of this in my second upcoming series.
Till then, happy experimenting with WebApi.
