Miguel A. Castro's Blog

# Monday, May 24, 2010

WCF 4.0 incorporates the features previously only obtainable via the REST Starter kit for .NET 3.5.  Among the features included is the ability to cache REST requests using a similar technique to caching ASP.NET pages.

The 4.0 version of the System.ServiceModel.Web assembly includes an attribute called AspNetCacheProfile which takes a string as an argument.  The attribute is to be used on a service contract operation as follows:

[OperationContract]
[WebGet(UriTemplate = "/{name}/getGreeting.xml",
        BodyStyle = WebMessageBodyStyle.Bare,
        RequestFormat = WebMessageFormat.Xml,
        ResponseFormat = WebMessageFormat.Xml)]
[AspNetCacheProfile("CacheFor10Seconds")]
string GetGreetingXml(string name);

 

The string points to a cache profile to be defined in the config section as follows:


    
        
            
        
    

 

As you can see, this is pretty much identical to setting up cache profiles for ASPX pages.  The effect is pretty much what you would expect, the caching of a REST request.  This can be proven and tested by implementing the above contract as such:

public string GetGreetingXml(string name)
{
    return string.Format("Hello {0}.  The time is {1}", name, DateTime.Now.ToLongTimeString());
}

 

Now you can refresh the request and you’ll see the same time for 10 seconds before it changes; once again, the same effect as in caching an ASPX page.

So what did I learn the hard way you ask?  Well, common sense dictates that the request go through ASP.NET in order to use its caching capability.  This not only means that you have to host in IIS or WAS, but also that you need to turn on ASP.NET compatibility mode.  This shifts the processing of the REST request over to an HTTP handler that also sets an HTTP Context for you, something not normally done with conventional IIS hosting for REST services.  To turn this on, you must enable it in the section under the section using the aspNetCompatibilityEnabled attribute.  Not only that, but you have to “allow” it on the service using the AspNetCompatibilityRequirements attribute.

This part was not a surprise for me since I was already familiar with this technique and the added scope your service receives because it.  I’m referring to the entire HTTP Context including session, application, cache, etc.  Keep in mind that this is not for everything and should be used in very specific scenarios as it ties the service to the hosting style quite tightly.

What drove me crazy is something I’m surprised I did not notice in the past and that is the fact that your REST requests will not work while using the Visual Studio development server.  Meaning you need to create an application in IIS and run it that way.  No big deal but it drove me a little crazy since the meta data exposure worked fine, and so did the new HTML Help pages (another new feature in WCF 4.0 For REST).  But the second I tried to request one of my URLs, it bombed out.  Once I set up my application under IIS, everything was fine.

I have to give credit where it’s due and thank Jon Flanders.  I found the answer in his book Restful .NET from O’Reilly press.

Until next time…

Monday, May 24, 2010 4:50:14 PM (Eastern Daylight Time, UTC-04:00)  #    Comments [0] - - Follow me on Twitter
Dev Stuff | WCF
Search
Me & My Flair

Read all about me here.
Download my Resume here.

Check out where I am here.
 
Click on logos above for profiles.
Archive
<May 2010>
SunMonTueWedThuFriSat
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
Statistics
Total Posts: 40
This Year: 0
This Month: 0
This Week: 0
Comments: 93