Currently, the API offers two parameters for control the cache layer:
force: when is true, revalidate the cache associated with the resource.
ttl: it establishes the time-to-live associated with the resource.
Need to deprecate force in favor of policy API parameters with the following possible values:
cache-first|standard|auto
This is the default value where we always try reading data from your cache first. If the value is not present in the cache, a new fresh cache copy will be generated and served.
refresh|fresh
It invalidates and serves a new fresh cache copy. It's the current behavior of force.
stale
It serves cache copy if it's present meanwhile asynchronously refreshes the value. It's equivalent to stale-while-revalidate.
only-if-cached
If the cache copy is a HIT, serve it; otherwise, it doesn't create a cached copy of the resource, returning a 404.
no-cache
It disables the cache level, serving always a fresh copy that will be not stored.
no-store
Similar to force but not creating a new fresh cache entry.
Currently, the API offers two parameters for control the cache layer:
force: when istrue, revalidate the cache associated with the resource.ttl: it establishes the time-to-live associated with the resource.Need to deprecate
forcein favor ofpolicyAPI parameters with the following possible values:cache-first|standard|autoThis is the default value where we always try reading data from your cache first. If the value is not present in the cache, a new fresh cache copy will be generated and served.
refresh|freshIt invalidates and serves a new fresh cache copy. It's the current behavior of
force.staleIt serves cache copy if it's present meanwhile asynchronously refreshes the value. It's equivalent to
stale-while-revalidate.only-if-cachedIf the cache copy is a HIT, serve it; otherwise, it doesn't create a cached copy of the resource, returning a
404.no-cacheIt disables the cache level, serving always a fresh copy that will be not stored.
no-storeSimilar to
forcebut not creating a new fresh cache entry.Inspiration