Skip to content

REST and YOU Part 2 – CacheCow and the Browser

November 27, 2012

In my last post I tried to give a basic introduction to Conditional GET requests and the part they play in caching. But as with most things HTTP the specification is one thing, implementing it is a completely different kettle of fish altogether. Luckily, in our case there is a cracking implementation of caching via conditional GET requests already provided… the CacheCow Framework by Aliostad.

CacheCow comes in two flavours… CacheCow.Server and CacheCow.Client. As the names suggest, they help with providing and consuming APIs respectively. There is a thorough explanation of both these tools on Aliostads blog so I won’t go into detail about how to get set up… suffice to say it’s very straightforward.

spc

Now CacheCow.Client is very useful if you are consuming APIs directly from .NET, but what about us who want to consume from JavaScript via ajax? Well we’re in luck… with the appropriate response headers coming from the server, all modern browsers will keep track of ETag and Last-Modified values and then accordingly send conditional GET requests instead of using their internal cache. And whats more, CacheCow.Server takes care of setting those headers. Brilliant!

For quick reference (if you’re interested), the following response headers should ensure the correct behavior from all modern browsers:

  • Cache-Control: max-age=0
  • Expires: -1 (This is technically a response content header)
  • Pragma: no-cache

Just be sure not to set the Cache-Control: no-cache header as then the browser will cache nothing whatsoever!

spc

Here’s a contrived example so you can see it in action:

ValuesController.cs

public class MyResponse
{
    public string Name { get; set; }
    public string Title { get; set; }
}

public class ValuesController : ApiController
{
    private MyResponse obj;

    public ValuesController()
    {
        this.obj = new MyResponse() { Name = "Test", Title = "Test" };
    }

    public HttpResponseMessage Get()
    {
        return new HttpResponseMessage()
        {
            Content = new ObjectContent(obj, new JsonMediaTypeFormatter())
        };
    }
}

Index.html

    <pre id="output"></pre>
    <button id="getButton">Get Data</button>

    <script type="text/javascript">
        $.ajaxSetup({headers: {
            accept: "application/json",
            "content-type": "application/json"}});

        $(document).ready(function () {
            $("#getButton").click(function () {
                $.ajax("http://localhost/Api/Values", {
		    success: function (data) {
                        $('#output').text(JSON.stringify(data));
                    }
                });
            });
        });

    </script>>
spc

So pressing the button goes and gets some data from our API and displays it in the pre tag. Simples. I’ve also fired up Fiddler so I can see whats happening with my requests. I’ve also made sure to clear out my browser caches before I start.

Now because we have CacheCow.Server running on our API implementing the proper conditional GET behavior, we would expect the first request to return http 200 with content, and the second time we press the button we expect to get a http 304 (not modified). And thats exactly what we get in the “big three” browsers:

spc

So thats just how awesome CacheCow is, not only does it cater for consuming your API from .NET, it also works out of the box with your browser. Just make sure however that you don’t use the jQuery ajax option cache=false, as this will append a random querystring param to the end of your URI. Because this is not restful (in REST your resources should be uniquely identiable), CacheCow will not recognise that you are accessing the same resource and so will create another Cache entry.

Oh and lets not mention IE 6, 7, or 8. I’d be interested to hear what happens with these browsers though. And if anyone wants to let me know what happens in other browsers such as Safari or other Linux based browsers then I’ll publish the results. Cheers!

spc

Pete

spc
spc

References:

http://support.microsoft.com/kb/234067?wa=wsignin1.0
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
http://www.webscalingblog.com/performance/caching-http-headers-cache-control-max-age.html

Advertisements

From → REST, Web API

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: