How to enable sessions in Web API

Web API does not support native HTTP sessions. And it’s the nature of Web API, but there might be times you need HTTP sessions which resembles your bad design. Because a service framework should not support HTTP sessions as it should be a stateless element. So why do we need sessions in Web API ? I think you should not use sessions in Web API in production; eliminate HTTP sessions completely.

So the answer for the question why do we need sessions in Web API is, just to show how you can enable them. Silly though but you can use this in developing some POC and quick functional demos. Never use sessions in Web API because Web API is designed to be stateless.

First we should implement a ControllerHandler which is capable of handling sessions. In order make our ControllerHandler handle sessions we should implement IRequiresSessionState interface as well. Look at the below code.

   1: public class SessionableControllerHandler : HttpControllerHandler, IRequiresSessionState

   2: {

   3:     public SessionableControllerHandler(RouteData routeData) 

   4:         : base(routeData)

   5:     {


   7:     }

   8: }

The next step is to create a RouteHandler as a wrapper to the ControllerHandler we created, this is because when registering routes in the RouteTable we can pass RouteHandler types not ControllerHandler types. Look at the below code for the custom RouteHandler.

   1: public class SessionStateRouteHandler : IRouteHandler

   2: {

   3:     public IHttpHandler GetHttpHandler(RequestContext requestContext)

   4:     {

   5:         return new SessionableControllerHandler(requestContext.RouteData);

   6:     }

   7: }

Then finally we have to register our RouteHandler in the RouteTable

   1: RouteTable.Routes.MapHttpRoute(

   2:     name: "DefaultApi",

   3:     routeTemplate: "api/{controller}/{id}",

   4:     defaults: new { id = RouteParameter.Optional }

   5: ).RouteHandler = new SessionStateRouteHandler();

In order to make our custom route to be used we need to put it on top of other route registrations.


Crossdomain.xml – Flex

When accessing the web services in Flex you need a crossdomain.xml file in the root of the web server which hosts the web service. In the file you can mention whether to accept the connections from all the domains or the connections from the specific domains to be accepted.

Here the sample for a crossdomain.xml file which allows the access from all the domains.

   1: <?xml version="1.0" ?>

   2: <cross-domain-policy>

   3:    <allow-access-from domain="*" secure="false" />

   4:    <site-control permitted-cross-domain-policies="all"/>

   5:    <allow-http-request-headers-from domain="*" headers="*"/>

   6: </cross-domain-policy>

For .NET guys, this is the exact similar version of the clientaccesspolicy.xml file we deploy in the root of the web server when working with Silverlight.

Web Services Simplified

This article will give you a compact explanation of web services. I explained the things in a compact manner because nobody want to read paragraphs of explanation 😀

Let’s start the discussion with a real world example, we all know the role of the web applications. We also know the shopping cart apps. But the question is, if we really want to create a shopping cart for a company (let’s say M-entertainment online music store) we build our web site with high security concerns. We take the credit card number of the customer, then what ? Is it finished with that ? No.

The real work yet to be started. You take the credit card number then you have to validate that. Contact the specific bank or financial institute and make sure the availability of the account. Then you have to make sure whether the customer has enough credit limit. Then the company has to authenticate itself to the bank (it may be another bank). Then the system has to deduct the amount from the customer account and add it to it’s account. (If there are commissions to the bank it has to be allocated).

OOPS..There’s whole lot of things have to be done. :(. Just think we are a company and we build our website, we have a own database server (or hired one) and we have direct access to it. (we have the authentication). But to check whether the credit is there in customer’s account we have to connect to the bank’s database. Will they provide you the access to their database ? Definitely not.

So what is the solution ? To make your application work perfectly in a real world scenario you need the above functionality. And all the available web applications have the above functionality. So how this is possible ? The answer is web service. The bank gives an interface to interact with their data, this is a simple example for the web services. So web services are interfaces which can be used to interact with third party web applications.

Most commonly web services are implemented with XML and its derivatives. The main reason for this is, XML and XML based standards are platform independent and they are open standards recognized by the industry.

When it comes to interoperability and communication XML is not only the way to do that, but it is a well known and a leading way of describing data. So mostly the communication with the web services happen in the format of XML and derivatives. The derivatives in the sense it includes the other protocols like SOAP,WSDL and much more…

So as explained in the above example if you want to check the available balance of the customer, you have to communicate with the service provided by the bank. You pass the relevant detail of the customer as a parameter (credit card number or account number) to the web service and request the balance and you will get a web service response for your request in an XML format.

Again XML is not only the way to create the web services but it is commonly used because of its open standard and industry wide recognition. The XML based web services are called XML web services but when it is normally referred to as web services it means the XML web services.