Best Practices - Caching

From The Socknet

A Socknet agent makes two different kinds of HTTP calls regularly: OpenID page accesses which generally return HTML; and Socknet API accesses which return JSON. Both kinds may be cached.

Socknet Responses

A Socknet response may contain the field cache_time at the top-level. This field holds the number of minutes that the data in the response will likely remain valid. It may be a floating-point number.

The agent may choose to cache for a different amount of time or not at all in its discretion. Care should be taken to cache only calls which are not likely to change soon.

A Socknet response must only be cached in relation to a particular provider url, function name and request object (if any). These items must all match when accessing a cached response.

In general, it is appropriate to cache the response of any function which can accept a GET call.

OpenID

An agent may cache an OpenID page at its discretion for any amount of time. If an HTTP response includes appropriate headers, then the agent may use these to determine the best amount of time to cache for. Note: the HTTP mechanisms can get complex, so you'll be happiest if you have a library that can handle this for you. For example, Perl's HTTP::Response has a very nice fresh_until method.

When Cached Data is Inaccurate

If a user changes Socknet providers, any cached OpenID pages will point to the old provider. In this case, the old provider must refuse to accept new data (such as messages) but should still provide data (such as profile) for a limited time.

If an agent cannot determine where to send data, it should store it and resend it later. Presumably, the cache will expire in that time, but the agent may take the failure as a cue to flush the cache for that recipient.