[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-17。"],[],[],null,["# Local Databases\n===============\n\nThis document applies to the following method:\n[Update API](/web-risk/docs/update-api).\n\nDatabase setup\n--------------\n\nClients using the Update API are required to set up a local database and to\nperform an initial download of the Web Risk lists they want to work\nwith. See the\n[Full updates](/web-risk/docs/local-databases#full-updates) section below for more information\non how to perform the initial fetch.\n\nDatabase updates\n----------------\n\nTo ensure protection against the latest threats, clients are strongly\nencouraged to regularly update their local Web Risk lists using the\n[`threatLists.computeDiff`](/web-risk/docs/reference/rest/v1/threatLists/computeDiff)\nmethod.\n\nThe `threatLists.computeDiff` request specifies the list to be updated. If clients\nhave memory or bandwidth limitations, they can also use the request to set\nupdate constraints (see\n[Update Constraints](/web-risk/docs/update-constraints)).\n\nThe `threatLists.computeDiff response` returns\neither a full update or partial update for each list, as explained below.\n\n### Full updates\n\nFull updates are returned when the client leaves the `versionToken` field in the\n[threatLists.computeDiff request](/web-risk/docs/update-api#http_get_request)\nempty or when the server determines a full update is required. For full updates,\nonly [additions](/web-risk/docs/local-databases#additions) are\nreturned. The client is expected to *clear the local database* before applying\nthe updates and performing the\n[validation check](/web-risk/docs/local-databases#validation-checks).\n\n#### Empty state\n\nFull updates are returned when the client sends the initial request for a list.\nIn this case, the `versionToken` field in the request is left empty (because\nthere is no value to provide) and the `newVersionToken` field in the response\nreturns the initial state for the local list. Full updates are also returned\nwhen the client purposely leaves the `versionToken` field empty on subsequent\nrequests. This will force a full update and return a new state in the\n`newVersionToken` field of the response.\n\n#### Server decision\n\nOccasionally, the Web Risk server returns a full update when only a\npartial update was requested by the client. This can happen when the client\ninitially downloads a small version of the list and then updates to a larger\nversion of the list; the server will simply return a full update with the entire\nlist. This can also happen if the client hasn't downloaded data in a long time\nand requests a partial update; again, the server will simply return a full\nupdate with the entire list.\n\n### Partial updates\n\nPartial updates are returned when the client supplies a value for the\n`versionToken` field in the\n[`threatLists.computeDiff` request](/web-risk/docs/update-api#http_get_request)\n(the exception, as noted above, is when the server determines a full update is\nrequired). For partial updates, both\n[additions](/web-risk/docs/local-databases#additions) and\n[removals](/web-risk/docs/local-databases#removals) are\nreturned. The client updates the lists in the local database (applying the\nremovals before the additions) and then performs the\n[validation check](/web-risk/docs/local-databases#validation-checks).\n\n### Additions\n\nAdditions are SHA256 hash prefixes that should be added to the local database.\nMost hash prefixes are 4 bytes long but some hash prefixes could\nhave any length between 4 and 32 bytes. Therefore, multiple sets of additions\ncould be returned; for example, one containing the 4-byte prefixes and one\ncontaining 5-byte prefixes.\n\nIf the client supports compression, the response can be compressed using Rice\ncompression. However, only 4-byte hash prefixes get compressed. Longer hash\nprefixes are always sent in uncompressed, raw format. For more details, see\n[Compression](/web-risk/docs/compression).\n\n### Removals\n\nRemovals are zero-based indices in the lexicographically-sorted client database\npointing at entries that should be removed from the local database. Only one set\nof removals will be returned.\n\nIf the client supports compression, \"rice hashes\" and \"rice indices\" are\nreturned. If compression is not supported, \"raw hashes\" and \"raw indices\" are\nreturned. For more details, see [Compression]()/web-risk/docs/compression).\n\nValidation checks\n-----------------\n\nWhen the\n[`threatLists.computeDiff` response](/web-risk/docs/update-api#http_get_response)\nis returned; with either a full update or a partial update; the client is\nexpected to perform a validation check.\n\nThe client first updates the lists in the local database (applying the removals\nbefore the additions). The client then computes the SHA256 hash of the\n(lexicographically sorted) local list and compares it to the checksum returned\nin the response. If the two values are equal, the Web Risk list is\nconsidered \"correct.\"\n\nIf the two values are not equal, the Web Risk list is considered\n\"corrupt.\" The client must clear the list from the database and reissue a second\nupdate with the `versionToken` field set to the empty string; this will force a\nfull update and return a brand new list and state."]]