Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Frekuensi Permintaan
Permintaan pembaruan
Untuk mencegah server kelebihan beban dan mendapatkan perlindungan yang optimal, Update
API menerapkan interval waktu untuk frekuensi klien dapat mengirim permintaan ke
server Risiko Web untuk melakukan pemeriksaan URL
(hashes.search)
atau mengupdate database lokal
(threatLists.computeDiff).
Permintaan awal untuk data harus terjadi pada interval acak antara 0 dan 1
menit setelah klien dimulai atau aktif. Permintaan berikutnya hanya dapat terjadi
setelah batas waktu
durasi tunggu minimum
atau
mode back-off
diikuti.
Jika kolom minimumWaitDurationtidak ditetapkan dalam
respons, klien dapat melakukan update sesering yang diinginkan dan mengirim sebanyak mungkin
permintaan threatListUpdates atau fullHashes.
Jika kolom minimumWaitDurationditetapkan dalam respons,
klien tidak dapat memperbarui lebih sering daripada durasi tunggu. Misalnya, jika respons fullHashes berisi durasi tunggu minimum 1 jam,
klien tidak boleh mengirim permintaan fullHashes apa pun hingga jam tersebut berlalu,
meskipun pengguna mengunjungi URL yang awalan hash-nya cocok dengan database lokal.
(Perhatikan bahwa klien dapat melakukan update lebih jarang daripada durasi tunggu minimum, tetapi
hal ini dapat berdampak negatif pada perlindungan.)
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["# Request Frequency\n=================\n\nUpdate requests\n---------------\n\nTo prevent server overload and to benefit from optimal protection, the Update\nAPI imposes time intervals for how often a client can send requests to the\nWeb Risk server to perform URL checks\n([`hashes.search`](/web-risk/docs/update-api#example-hashessearch))\nor to update the local database\n([`threatLists.computeDiff`](/web-risk/docs/update-api#example-threatlistsComputediff)).\n\nThe initial request for data must happen at a random interval between 0 and 1\nminutes after the client starts or wakes up. Subsequent requests can happen only\nafter the\n[minimum wait duration](/web-risk/docs/request-frequency#minimum_wait_duration)\nor\n[back-off mode](/web-risk/docs/request-frequency#back_off_mode)\ntime limit has been observed.\n\nMinimum wait duration\n---------------------\n\nBoth the\n[hashes.search response](/web-risk/docs/update-api#http_post_response_2)\nand\n[threatLists.computeDiff response](/web-risk/docs/update-api#http_post_response)\nhave a `minimumWaitDuration` field that clients must obey.\n\nIf the `minimumWaitDuration` field **is not set** in the\nresponse, clients can update as frequently as they want and send as many\n`threatListUpdates` or `fullHashes` requests as they want.\n\nIf the `minimumWaitDuration` field **is set** in the response,\nclients cannot update more frequently than the length of the wait duration. For\nexample, if a `fullHashes` response contains a minimum wait duration of 1 hour,\nthe client must not send send any `fullHashes` requests until that hour passes,\neven if the user is visiting a URL whose hash prefix matches the local database.\n(Note that clients can update less frequently than the minimum wait duration but\nthis may negatively affect protection.)\n\nBack-off mode\n-------------\n\nFor the recommended backoff procedure, read our\n[Service Level Agreement](/web-risk/sla)."]]
