Tuesday 17 January 2017

API; what and why?

API; what and why?

Let’s start right at the start and figure out what an API is and why you should consider using one.
The term API stands for ‘Application Programming Interface’. In the world of web development the term ‘API’ is synonymous with online web services which client apps can use to retrieve and update data. These online services have had several names/formats over the years such as SOAP, however the current popular choice is to create a REST (or RESTful) API.
We’ll come onto REST and why REST is now preferred later, but first let’s examine why you would even bother with an API.
Let’s consider a modern application which may include several mobile apps on various platforms and usually some kind of web application too. Without an API, a basic architecture may look like this where each client app has its own embedded business logic.

Notice that each client app has its own embedded business logic (probably written in several different languages) which connects directly to the database to get, update and manipulate data. This local business logic means that the client apps can easily become complex and all need to be maintained in sync with each other. When a new feature is required, you’ll have to update each app accordingly. This can be a very expensive process which often leads to feature fragmentation, bugs and can really hold back innovation.
Now let’s consider the same architecture with a central API which hold all the business logic.

Each app uses the same API to get, update and manipulate data. All apps have feature parity and when you need to make a change you just make it in one place in line with the ‘Don’t Repeat Yourself’ (DRY) principle of software development. The apps themselves then become relatively lightweight UI layers.

Friday 6 January 2017

Where to use HttpHandler in ASP.Net Application

In this article we will understand a few more scenarios where we can implement HttpHandler in an ASP.NET application.

Count number of request to certain page
Yes, there might be some other solution for this problem but we can use HttpHandler to count the number of hits to a certain page. Here is the implementation of trying to count the hits of a Home.aspx page. At first we are checking the request URL. If the URL contains “Home.aspx” then we will increment the count value by one.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
 
namespace WebApp
{
    public class countHandler : IHttpHandler
    {
        static int CountRequest = 0;
        public void ProcessRequest(HttpContext context)
        {
            if (context.Request.RawUrl.Contains("Home.aspx"))
            {
                CountRequest++;
            }
         }
        public bool IsReusable
        {
            get
            {
                return false;
            }
        }
    }
}
The handler is realy simple and now we need to register the handler. Add the following code to your web.config file.
</system.webServer>
  <handlers>
    <add name="myImageHandler" verb="*" path="*.aspx" type="WebApp. countHandler"/>
  </handlers>
</system.webServer>
Ok, we have finished our implementation part. Now let’s try to call the Home.aspx page in a browser. After calling the Home.aspx page, our handler will execute and it will increase the “CountRequest” value by one.

We are seeing that now the CountRequest value is 2, because the output screen has taken in the second trial.

Count number of request

Redirect one page from other page
This is another possible scenario where we can implement HttpHandler as a solution. Let’s think about a situation where one web page exists but then it no longer exists but your client thinks that the page is still in the application.

Now to solve this problem we need to redirect the HTTP request of that page to some other page. For the redirect operation we can use HttpHandler. Have a look at the following code.

In this implementation if someone tries to reach the Home.aspx page then she will redirect to the abc.html page. In this way we can implement redirection.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
 
namespace WebApp
{
    public class loginHandler : IHttpHandler
    {
        public void ProcessRequest(HttpContext context)
        {
            if (context.Request.RawUrl.Contains("Home.aspx"))
            {
                context.Response.Redirect("abc.html"); 
            }
        }
 
        public bool IsReusable
        {
            get
            {
                return false;
            }
        }
    }
}
The registration of a HttpHandler is very similar to the previous example. Now if we try to reach the Home.aspx page then it will automatically be redirected to the abc.html page.
Redirect one page from other page

Check whether or not a cookie is present in the current HTTP request
This is another possible scenario. Again , there might be another solution for that but we can implement HttpHandler to detect cookies in HTTP requests.

The count property of the HttpContext class will tell the number of cookies in the current HTTP request. In this example we are detecting the cookie count, if the count is more than 0 then we will consider that the cookie is present in the current HTTP request and we will drop that request immediately.

Here is the implementation:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
 
namespace WebApp
{
    public class loginHandler : IHttpHandler
    {
        public void ProcessRequest(HttpContext context)
        {
            if (context.Request.Cookies.Count > 0)
            {
                context.Response.ContentType = "text/plain";
                context.Response.Write("Please don't send cookie in HTTP Request");
            }
        }
 
        public bool IsReusable
        {
            get
            {
                return false;
            }
        }
    }
}
The registration process of HttpHandler is similar to the previous example, there is no change in that. So that we are skipping that part.

When we will now try to browse the “home.aspx” page (or any .aspx page, because our handler will detect the .aspx page request). We will see the default message rather than the page contents. The reason is, we are sending the SessionId from cookies.

current HTTP request