How to Enable CORS in the ASP.NET Web API

Have you ever come across the following error:

Cross-origin Request Blocked. The same origin policy disallows reading the resource”.

Us to! It turns out, we get this error due to lack of CORS support while sharing resources. When we try to consume the Web API from origin A in a web application residing in origin B, we get the above error. To solve this error, we need to have a good understanding of CORS.

Although the purpose of this article is to learn the practical implementation of enabling CORS in the ASP.NET Web API, we will give a fair amount of weight to the theoretical concept also. CORS stands for Cross-Origin Resource-Sharing. For various security reasons user agents cannot share resources if they are not from the same origin. Various examples of user agents are browsers, HTML documents, scripts, and XMLHttpRequest.

Let us try to understand the concepts of Cross-Origin and Same-Origin. The concept of Origin was described by RF 6454. Two URLs would be called of the same origin, if they have:

  1. Scheme (http)
  2. Host (server)
  3. Port (8888)

The Origin consists of the Scheme, Host, and the Port number.


If two resources have the same combination of scheme, host, and port then they are considered of the same origin, else of the cross origin. Let us consider the following two URI and are not of the same origin since their host and port are not the same. For the security reason resource sharing between these two URL may be restricted. Let us try to understand CORS with the example of XMLHttpRequest. We use the XMLHttpRequest to perform the HTTP operation on the server from the HTML document. There are two URLs used in the XMLHttpRequest:

  1. Requested URL or URL of the server
  2. URL of the document which initiated the request

If both URLs have the same scheme, host, and port then XMLHttpRequest object will perform the operation else it will block the HTTP operation for security reasons.

Both the server and the browser must have the support of the CORS. By default all recent browsers have CORS support, but as an API developer we need to enable support of CORS in the Web API.


Here we have created a very simple ASP.NET Web API which returns an array of classes as shown in the image below:

As you can see that Web API is running on port 8458. Next we are trying to get the data in a JavaScript application which is running on the URI with the port 5901:

Read the full article on the Infragistics blog

How to work with the Ignite UI Chart in an AngularJS application

In this post we will learn how to work with the Ignite UI chart in an AngularJS application. Although I will use the ASP.NET Web API to pull data from the database, you can use REST service or a Web API created on any stack with the Ignite UI charts in your AngularJS application. This article is divided in two sections:

  1. Section 1 : creating ASP.NET Web API using Code First approach
  2. Section 2 : using Ignite UI in AngularJS application

If you already have or know how to create the Web API REST Service (Note: from here on out in this post, we’ll use the term “Web API” to refer both to REST Service and Web API), you can jump to section 2 of this article. On the other hand if you need help in how to create ASP.NET Web API start from the section 1. Here’s a high level flow of diagram of an application::


Read full article on the Infragistics blog

Creating an ASP.NET Web API using the Entity Framework Code First approach and the Repository pattern

In this article, we will learn how to create an ASP.NET Web API using the Repository pattern and the Entity Framework code first approach. Essentially you’ll learn how to:

  1. Create a core project which will contain entity and the repository interface;
  2. Create an Infrastructure project which will contain database operations code using the Entity Framework code first approach;
  3. Create a Web API to perform CRUD operations on the entity;
  4. Consume the Web API in a jQuery application and render the data in the Ignite UI Chart.

What is a Repository pattern?

Let us first understand why we need a Repository pattern. If you do not follow a Repository pattern and directly use the data then the following problems may arise-

  • Duplicate code
  • Difficulty implementing any data related logic or policies such that caching
  • Difficulty in unit testing the business logic without having the data access layer
  • Tightly coupled business logic and database access logic

By implementing a repository pattern we can avoid the above problems and get the following advantages:

Business logic can be unit tested without data access logic

  • Database access code can be reused
  • Database access code is centrally managed so easy to implement any database access policies such that caching
  • Easy to implement domain logics
  • Domain entities or business entities are strongly typed with the annotations.

Now that we’ve listed how great they are, let’s go ahead and start implanting a repository pattern in the ASP.NET Web API.

Create the Core project

In the core project you should keep the entities and the repository interfaces. In this example we are going to work with the City entity. So let us create a class City as shown in the listing below:

Read the full article on the Infragistics blog

How to perform a CRUD operation on the jQuery igGrid with the ASP.NET Web API

In this post we will learn how to perform a CRUD operation on the igGrid using the ASP.NET Web API, including:

  • Creating the ASP.NET Web API using the Entity Framework database first approach
  • Performing a CRUD operation on the igGrid in a jQuery application

At the end of the post we should able to create Web API for CRUD operations on the City entity and perform the CRUD operations from the igGrid.

Read full article on the Infragistics blog

Don’t Create REST APIs with WCF REST Services…use Web API Instead

There was time when developers used to create Web Service using the WCF. Their argument was using basicHttpBinding makes a WCF service as a Web Service. Yes that ASMX based web service. I never agree to this argument.


Clearly WCF was an evolvement over ASMX Web Service. Now let us talk about purpose of this article, that saga of Web API and REST Service. To start with let us understand the background.



A typical REST Service in WCF would look like as follows:


Point to be noticed here is that while creating the service we are defining the resource type. Since in above service we want to work with both JSON and XML message format, we are creating two services for the same.

EndPoint for REST Service can be created using the factor as shown in the snippet below,


This is the simplest WCF REST Service one could create. We can have different HTTP operations on the same URL. We can perform HTTP GET, POST, PUT, DELETE on the same resource URL in the WCF REST service. However while creating the service, we need to take care of the message format. WCF REST service use the WCF channel and messaging architecture which is used in the WCF SOAP service.


This is based on the ASP.NET MVC architecture to create an API for the web. We can create a RESTful API using the ASP.NET Web API. A simple Web API is a class which inherits ApiController class.


Keep in mind that ASP.NET Web APIs does not have the EndPoints and bindings. It utilizes the ASP.NET MVC routings to resolve the resources. Here resource describes their own capabilities and interactions.

To understand difference between REST Service and ASP.NET Web API, let us try to understand The Richardson Maturity Model.

RMM: Richardson Maturity Model classify an API into different levels on the basis of how well they use or take advantage of the web.


There are four levels in the RMM from level 0 to level 3.


Now we know different levels of RMM, so let us try to map WCF REST Service and the ASP.NET Web API to RMM.

In WCF REST Service

  • Can have multiple URI
  • Can have multiple HTTP methods
  • Operations are defined by the URI
  • Each operation has its own URI
  • Each URI cross ponds to a method on the server.

Let us examine nature of REST Service. Let us assume we want to perform CRUD operation on the BloodDonor table. WCF REST Service allows us to have different methods on the same URI. So it is very much resource oriented. Resource is uniquely identified by the URI and we can have multiple HTTP method on the same resource or URI. A WCF REST Service for CRUD operation may look like as shown in the listing below,


Before we conclude that WCF REST Service can be placed in the level 2, there is a catch in it. Above created WCF REST does not know the content negotiation. Client cannot request for a particular type of content and can only work with the XML message format (in this case). WCF REST service cannot negotiate with the resource on the same URI in the multiple message format.


Now let us focus on the ASP.NET Web API. It can be also be placed in the level 2 with content negotiation and the support for multiple message format on the same URI.


A typical ASP.NET Web API may look as shown in the listing below,


ASP.NET Web API have single URI for multiple operations working on different HTTP methods. However unlikely WCF REST, while accessing ASP.NET Web API, client can negotiate the content. Client can pass the message formant want to work with.

Let us see this in action using the Fiddler. In the fiddler when we pass content type as XML, ASP.NET Web API will return response in XML message format as shown in the image below,


In the fiddler when we pass content type as JSON, ASP.NET Web API will return response in JSON message format as shown in the image below,


Clearly in the ASP.NET Web API client can pass the message format in the request header. Some other characteristics of the ASP.NET Web API over the WCF REST Service is as follows:

  • Unit Testability
  • Support for multiple format
  • Symmetric programming experience at client and server
  • Multiple hosting options

By discussion so far we can say you don’t create REST Service using the Web API. Web API is has more features to put itself in the level 2 of the Richardson Maturity Model.

image I am sure this is a subjective discussion, so would love to read your thought on the same. Feel free to comment your view on my understanding.

Happy coding.