You are here:
Caching
Unauthenticated GET methods are normally cached on the server. Every cached method will send a cache hint in the response telling when the cache expires. A similar subsequent call made before the expiration date will yield identical results. Applications using our API should take these cache hints into account in order to minimize traffic and the risk of exceeding their allocated request rate limit.
Here is an example of a cache hint response header:
Cache-Control: max-age=59 Expires: Fri, 25 Sep 2009 11:54:06 GMT
Searches are cached using a different mechanism. This type of caching is based on the search parameters, and not the URL/request headers. This means that two similar requests of different formats made within the caching time span will return equivalent results in their respective formats. No cache headers are returned in this case.
E-Tags
E-Tags can be used to cache catalogue data (categories, regions, etc) locally while still ensuring you have the latest data. E-Tags are supported for all Catalogue APIs.
This works as follows:
- All catalogue methods will now return an ETag header, like this:
ETag: “686897696a7c876b7e” - You are expected to save this somewhere, and then when you want to check for updated data, add this header to the request:
If-None-Match: “686897696a7c876b7e” - The response will either be 200 OK (with the new data) or 304 Not Modified (with no response body). If the response is 304 then you can continue to use the cached data.