Something Special Making it EVEN better.

Attempting to not break the web

In my last post, "Google is breaking the web!", I discussed various approaches to customizing REST responses for mobile clients. The problem is, of course, complicated by reality and the fact that there are so many devices with varying abilities. What I discovered in my quest for fantastic cacheability and making client devs and device owners happy was something like the following. First we looked at using some standard approaches to determining the client type and version, followed by some unconventional ones.

• User-Agent header: S60 sets this but the S60 browser overrides it
• Accept header: N900 can't set this
• X-User-Agent header: non-standard and N900 can't set this right now (maybe later though)
• Dot notation (/places/placeid.json+{opaque string}): complex to implement on the server side with regular expression matching and more importantly, not forwards compatible (i.e. server will not ignore this if it doesn't understand it, instead a 404 is returned)
• Matrix parameter (/places/placeid;filter={opaque string}): semantically the wrong use of this -- matrix parameters are meant to select resources based on non-hierarchical selection (i.e. choosing a position in 2D space, lat/long)

In the end, it was decided that an opaque string as a request parameter would satisfy the requirements:

• must be cachable
• a cache entry usable by any client and not tied to the client type or version number (this one is key)
• usable from devices we have now and future devices
• usable from web/AJAX requests
• usable from embedded JavaScript/jsonp type scenarios

The query parameter we use is called filter and the value should be a short opaque string of length 3 (for now). The short opaque string should be randomly generated alphanumeric string to avoid assumptions about the meaning of the filter and to reusable by as many devices and software versions as possible, thereby optimizing cache hits.

As to the cacheability of a query parameter, some research was done but it was determined that it is acceptable for the two caching cases we care about:

• Varnish: A hash of the complete URI is performed including the query parameter.
• Akamai/CDNs: According to a user report, Akamai will indeed cache an entity even with a query parameter, so long as it has seen the exact same request before (same as Varnish) and cache control headers have been sent from the server.

Apparently some older caches will not do as Varnish does and just take a hash of the URI, but at some point you have to make some assumptions and admit that you won't get the solution 100% perfect.