type: "INSTANT"Refresh Job. This means the very first request to an HTML file that has not been refreshed yet, will return the currently cached version and trigger an immediate update in the background. All requests and users after that will get the fresh content from the cache. This ensures that popular sites are updated instantly while maintaining an optimal cache hit rate.
type: "DEPLOYMENT"you can even force the CDN to be purged hard so no cached content is served afterwards.
filter- A filter to restrict the refreshing assets. The filter can contain the following attributes
mediaTypes- Restricting the exact media types to refresh
contentTypes- Restricting the content types to refresh. For Example:
["script", "style"]. Possible values are:
urls- Matching an array of URLs. URLs can include the wildcard character
*. For Example:
prefixes- Matching URLs via given prefixes
tags- Matching tags which was previously set with the
Baqend-TagsHTTP header when the asset is fetched from the origin
query- Containing a MongoDB query to restrict which resources to refresh. This lets you combine attributes with AND and OR or even execute regular expressions. The query can use the following metadata fields:
triggeredBy- Allows to define a name of a routine or person which triggered the job. Default is
allowDelete- Defines whether a refresh job can delete assets if they are unused or gone. Default is
type- Defines how the refresh is carried out. The following values are supported. Default is
"REFRESH"- A standard refresh job that iterates through resources and refreshes them. Resources that are not yet refreshed will still served the cached version.
"INSTANT"- The server will not serve cached content until it is refreshed and also do a soft purge against the CDN. This means the first request of a user against the CDN will see a cached version and triggers a refresh in the background, subsequent requests will be fresh. This is a nice trade off to keep cache hit rates high and still update popular resources very fast. Note: should be used to refresh a large amount of HTML files
"DEPLOYMENT"- A deployment refresh purges the cache immediately and builds it up again lazy. This means cache entries are immediately up to date. This will cause a performance drop and should only be used if the HTML structure have been changed. (e.g. after a deployment of the origin) Note: only supported for HTML files.
"PURGE"- Our caches will receive a complete purge for the marked assets. This will drop all resources from our caches. The cache will not be build up again for the purged resources. Note: this will dramatically impact the performance and should only be used to delete unwanted cached resources from our caches.
forceUpdate- Forces to also update resources that are marked as immutable because they contain a hash and have high caching headers. Default is
delay- Defines a wait time between batches of refreshed resources. This option can be used to minimize the traffic to the origin server if necessary but makes the refreshes take much longer. Default is
scheduleIn- Allows to define a time span in ms the job scheduler will wait until the refresh job is actually scheduled to run. Default is
name- Set a name for the refresh job to make it easier identifiable. Default is
content-type: application/json;charset=utf-8containing a
statusIdthat can be used to query the status of the refresh via a GET request to the same endpoint.
revId- The revalidation ID is equal to the
statusIdfrom the request
filter- Contains all the details of the refresh that was created via POST
assetCount- Contains the number of resource matched by the refresh
refreshedCount- Contains how many resources have been updated so far
changedCount- Contains how many resources have changed during the update
state- Contains the state of the refresh, value are
FINISHED- For refreshes that are completed
CREATED- The job was created and assets are being marked
RUNNING- The marking finished, the job is passed on to the revalidation loop
ERROR- An error occurred. The
errorproperty will hold more information on the cause.
CANCELLED- The job was cancelled either via API or by the job scheduler because another Instant job was running
SCHEDULED- The scheduler moved the job aside and waits the time specified in the
DEFERRED- Another job with the same filter is currently active, this job is deferred until the previous job finishes. Subsequent jobs with the same filter as the
DEFERREDjob are ignored
time- The current runtime of the refresh