If you’re not aware of the Optional or Named Parameters feature introduced in C# 4.0, take a look at this video before reading this article:

http://msdn.microsoft.com/en-us/vcsharp/ee460905.aspx

The Good:

1) This features will certainly help you reduce the number of overloads for your methods.

2) The calls to the methods will be more reader friendly.
Eg. SetUserName(lastName: “Hello”, firstName: “World”); // the user will know which value goes into which parameter without having to look up the method signature.

3) Calls to a lot of COM APIs will now be simpler

The Bad:

1) When you compile a code that calls a method using named parameters, the parameter name used in the call is stored at callsite (i.e. in the assembly where the method is being called). If the method is actually defined in a different assembly (say a library dll that your other projects use), then this can have unindented side effects. Lets say you change one of the parameter names in your method and compiled your library dll and deployed it without compiling the other projects that use it. If the order and type of your parameters hasn’t changed you could still get by, cos the caller simply calls the methods as they did in earlier versions of C#. The named parameter call is only for the benefit of the reader. However, if the type or order of the parameters have changed the you are in trouble. You’ll have to recompile all the projects that use your library to reflect this change.

2) Another, and more serious side effect would be when you are using optional parameters. The values of optional parameters are also stored on the callsite. Hence if you change the default value of any parameter in your library dll and deploy it without recompiling the projects that use it, then your method will continue to get the old default values! This could lead to some bugs.

The Learning:

Although this new feature is pretty useful, developers should be aware of these side effects. Think of parameter names and the default values as a part of your public interface, just like the name of your method. That will make you think hard before changing parameter names or default values.

REST follows

As mentioned in my previous post(RESTful implementation using .Net) i would like to share further lights on RESTful implementation using .net, this time on implementing friendly RESTful urls using HTTP Modules. Before getting into the post as such, i would like the audience to look into topics related to query string injection and prevention techniques as  RESTful urls mostly deal with query strings , HTTP GET, POST verbs, etc.

Friendly REST urls

As an example , for a url, (the below shown url is the same RESTful url, that i had implemented in my previous post(RESTful implementation using .Net) to get employee details).

http://isense.com/employeeprofile.asmx/GetInfo?empid=1

we can make it user friendly as below,

http://isense.com/employeeprofile/GetInfo/1 

i am going take this simple scenario and show how such friendly url rewriting can be implemented using HTTP Modules. Once we get the concept, we can go ahead in developing robust url rewriting engines.

HTTP Module

 HTTP Module is one of the extensibility feature and advantage provide in .Net Framework. This helps in intercepting and manipulating each of the http requests that comes  from the client to the server application. Now in order to provide meaningful RESTFul urls, i am going to make use of this advantage provided by the HTTP pipeline. Below diagram describes the HTTP pipeline and the components involved in a typical client server architecture involving .net.

In order to tap the incoming request using http module in our application (Web, Web service, etc) following things are to be performed.

Implementation

1. Creating Http Module class :

Add a normal class file to the application which implements  IHttpModule and its members,

System.Web.IHttpModule.Init(System.Web.HttpApplication)  &

System.Web.IHttpModule.Dispose().

The Init method can be made use to perform  initializations that are required and which also holds the handle to the HttpApplication object which  in turn has control over the request, response objects.

Here in the Init method, i am adding a event handler which processes the application’s begin request event.

public void Init(System.Web.HttpApplication app)
        {
            app.BeginRequest += new EventHandler(Rewrite_BeginRequest);

        }

then in my Rewrite_BeginRequest custom method,  i am adding a simple piece of code,which intercepts the incoming request url, checks for the user-friendly format ( these formats are to be predefined and shared to the consumers of the webs service as some manuals / guidelines, so that they get an idea on how to query for a particular data), if valid,  rewrites the url  to the original page with the desired & required parameters as query strings.

Pseudo code of the Rewrite_BeginRequest(object sender, System.EventArgs args) implementation,

1. Typecast the incoming sender object to the http application object in order to get the handle of request, response, context and other asp.net objects.

System.Web.HttpApplication Appl = (System.Web.HttpApplication)sender;

2. Tap the incoming request url, look for the friendly url pattern "/employeeprofile/GetInfo/€, if valid , crop , validate and store the id part which follows the pattern.(the valid employee id number like 1, 10, etc which comes as part of the ur after the pattern -  "/employeeprofile/GetInfo/1 ) .

3. Now, once the id is retrieved, rewrite the url to the original page by using,

Appl.Context.RewritePath("employeeprofile.asmx/GetInfo?empid=1");

That’s it, now the coding for the url rewriting is done. as this is a simple demonstration i have hard-code the urls, but when it comes to real-time implementation we can define the friendly url patterns and their respective redirection urls in some configuration file and create  a url redirection module / library /engine which performs the above pseudo logic.

 

2. Web Config entry:

Once the coding part is over, we need to configure the custom http module in the web config, hence forth ASP.Net engine recognizes the module and invokes it,

<httpModules>
              <add type="RESTFulService.RESTfulHandlerModule,RESTFulService"      name="RESTFulRewriter" /> </httpModules>

the type attribute, takes in classname, assemblyname as input.

the name attribute is any meaningful name.

I hope this post would be a starter point in the future implementation of a robust URL rewriter engine.