How Google Webrisk evaluates the expiryTime and negativeExpiryTime for a particular UpdateAPi request.
Sometimes GWR api return the response with an expirytime of 5-10 minutes and therefore we have to again make an API call to GWR after 5-10 minutes which is pretty soon.
Is there any way to optimise the expiryTime to reduce the cost ?
The expireTime and negativeExpireTime fields indicate until when the hashes must be considered either unsafe or safe respectively in Update API.
To reduce the overall number of hashes.search requests sent to Google using the Update API , clients are required to maintain a local cache. The API establishes two types of caching, positive and negative.
Positive caching (expireTime)
To prevent clients from repeatedly asking about the state of a particular unsafe full hash , each returned ThreatHash contains a positive cache time (defined by the expireTime field). The full hash can be considered unsafe until this time. A positive cache entry should be created or updated for the full hash per the expireTime field.
Negative caching(negativeExpireTime)
To prevent clients from repeatedly asking about the state of a particular safe full hash, the response defines a negative cache duration for the requested prefix (defined by the negativeExpireTime field). All full hashes with the requested prefix are to be considered safe for the requested threat types until this time, except for those returned by the server as unsafe. The hash prefix's negative cache duration should also be created or updated per the response's negativeExpireTime field.
For Example:
Assume a client with an empty cache visits example.com/ and sees that h(example.com/) is in the local database. The client requests the full-length hashes for hash prefix h(example.com/) and receives back the full-length hash H(example.com/) together with a positive cache expireTime of 5 minutes from now and a negative cache expireTime of 1 hour from now.
The positive cache duration of 5 minutes tells the client how long the full-length hash H(example.com/) must be considered unsafe without sending another hashes.search request. After 5 minutes the client must issue another hashes.search request for that prefix h(example.com/) if the client visits example.com/ again. The client should reset the hash prefix's negative cache expireTime per the new response. Refer to the link for more information about Update API .
