6.6 Query Caching

The feeds returned by SData queries can be cached. SData relies on the standard HTTP caching mechanisms for this. Two cases come to mind:

1. The service provider knows how long the result will be valid.

2. The result may remain valid for some time but the provider does not know how long this would be.

Caching with Expires

The first case occurs when the information is refreshed by a periodic process and not modified between process runs. The service provider should set the Expires HTTP header in its response. The service consumer can rely on this expiry date to cache the response.

For example, if the service provider exposes currency rates that are refreshed every night at 3 am GMT, the response to an HTTP GET on /sdata/myApp/myContract/-/currencyRates SHOULD contain the following HTTP header:

Expires: Mon, 13 Apr 2008 03:00:00 GMT

The consumer can cache the result of this query until 3 AM GMT.

Caching with ETag

The second case is the common where data can be modified by users or processes at any time. In this case, SData recommends the use of the HTTP “strong ETag” mechanism to control caching. For example:

• The service provider SHOULD include an ETag HTTP header in its response.

ETag: “obIymRyfObO1lOar408hug==”

• The consumer can cache the response. When needed, it should send the request again to the service provider with the following If-None-Match HTTP header:

If-None-Match: “obIymRyfObO1lOar408hug==”

• The service provider can use this value to test if the resource has changed or not. If the resource has not been modified, the service provider SHOULD return an empty response with a 304 HTTP status:

304 Not Modified

• Whereas, if the resource has been modified, the service provider MUST return a 200 status code with the new ETag value and the new feed:

200 OK
ETag: “xaR0isqeM0S4thAktHRaRQ==”
 
<feed ...>

Options for ETag values

The ETag value MUST be a value that changes whenever the feed changes. HTTP and SData do not specify what this value represents nor how it is calculated. Here are some possibilities for the ETag value:

• Modification timestamp: If the feed data comes from a table and if the service provider keeps track of the last time the table was modified, it can use the table modification timestamp as ETag value. If the data comes from a file, the service provider can use the file modification stamp.

• Counter: If the service provider increments a counter every time the feed data is modified, it can use the counter as ETag value.

• Hash: The service provider can also compute a hash on the feed data and use it as ETag value.

As a general rule, modification stamps and counters are more efficient than hashing as they don’t need to retrieve and hash the data feed. Hashing is usually the only solution when the service provider can’t get a last modification date or a counter.

Strong etags are also used to detect concurrent modifications. To support this, etag values are associated with individual entries rather than the whole feed. It is important that feed-level etags and entry-level etags are not confused. Nevertheless, feed-level etags can be calculated from the entry etag values. For example, if the entries use modification timestamps as etag values, the feed can set its etag to the most recent timestamp found in the entries. If the entries carry a hash as etag, the feed-level hash can be calculated by a hash on the combined entry-level hashes.

SData providers MAY implement this caching protocol.

---