错误响应
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
标准错误响应
如果 Tag Manager API 请求成功，该 API 会在响应正文中随请求的数据一并返回 200 HTTP 状态代码。
如果请求出现错误，该 API 会根据错误类型在响应中返回 HTTP 状态代码和原因。此外，响应正文还将详细说明出错的原因。下面是一个错误响应示例：
400 invalidParameter
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "accessNotConfigured",
"message": "Access Not Configured. Please use Google Developers Console to activate the API for your project.",
}
],
"code": 403,
"message": "Access Not Configured. Please use Google Developers Console to activate the API for your project."
}
}
注意：说明随时可能发生变化，因此应用不应受实际说明文字的局限。
实现指数退避
指数退避是指客户端按照不断增加的时间间隔定期重试失败的请求的过程。这是网络应用的标准错误处理策略。Tag Manager API 在设计时就已考虑到了客户端可能会使用指数退避重试失败的请求。这除了是一项“要求”外，使用指数退避还能提高带宽使用效率、减少获得成功响应所需的请求数，并最大程度地提高并发环境中的请求吞吐量。
实现简单指数退避的流程如下。
- 向 API 发出请求。
- 收到错误响应，其中包含一个可重试的错误代码。
- 等待 1 秒 +
random_number_milliseconds 秒。
- 重试请求。
- 收到错误响应，其中包含一个可重试的错误代码。
- 等待 2 秒 +
random_number_milliseconds 秒。
- 重试请求。
- 收到错误响应，其中包含一个可重试的错误代码。
- 等待 4 秒 +
random_number_milliseconds 秒。
- 重试请求。
- 收到错误响应，其中包含一个可重试的错误代码。
- 等待 8 秒 +
random_number_milliseconds 秒。
- 重试请求。
- 收到错误响应，其中包含一个可重试的错误代码。
- 等待 16 秒 +
random_number_milliseconds 秒。
- 重试请求。
- 如果错误仍然出现，则停止重试并记录错误。
在上述流程中，random_number_milliseconds 是一个小于或等于 1000 的随机毫秒数。必须这样做才能在一些并行实现中避免某些锁定错误。random_number_milliseconds 必须在每次等待后重新定义。
注意：等待时间始终是 (2 ^ n) 秒 + random_number_milliseconds 毫秒，其中 n 是单调递增的整数，初始值为 0。变量 n 在每次迭代（每次请求）后递增 1。
该算法设置为 n 为 5 时终止。设置这个上限只是为了防止客户端无限重试，以便在大约总共 32 秒的延迟后，将请求认定为“不可恢复的错误”。
下面的 Python 代码就是上述流程的实现示例，旨在从名为 makeRequest 的方法出现的错误中恢复过来。
import random
import time
from apiclient.errors import HttpError
def makeRequestWithExponentialBackoff(tagmanager):
"""Wrapper to request Google Tag Manager data with exponential backoff.
The makeRequest method accepts the tagmanager service object, makes API
requests and returns the response. If any error occurs, the makeRequest
method is retried using exponential backoff.
Args:
tagmanager: The tagmanager service object
Returns:
The API response from the makeRequest method.
"""
for n in range(0, 5):
try:
return makeRequest(tagmanager)
except HttpError, error:
if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded']:
time.sleep((2 ** n) + random.random())
print "There has been an error, the request never succeeded."
如未另行说明，那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可，并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情，请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-08-29。
[null,null,["最后更新时间 (UTC)：2025-08-29。"],[[["\u003cp\u003eTag Manager API returns a \u003ccode\u003e200\u003c/code\u003e HTTP status code for successful requests and provides detailed error information in the response body for unsuccessful ones.\u003c/p\u003e\n"],["\u003cp\u003eApplications should implement exponential backoff when retrying failed Tag Manager API requests to optimize bandwidth and throughput.\u003c/p\u003e\n"],["\u003cp\u003eExponential backoff involves retrying requests with an increasing delay, calculated as (2 ^ \u003cem\u003en\u003c/em\u003e) + a random number of milliseconds, where \u003cem\u003en\u003c/em\u003e increases with each retry.\u003c/p\u003e\n"],["\u003cp\u003eThe retry process typically terminates after a total delay of approximately 32 seconds if the error persists.\u003c/p\u003e\n"],["\u003cp\u003eAn example Python implementation demonstrates how to incorporate exponential backoff into API request handling.\u003c/p\u003e\n"]]],["The API returns a `200` status for success, otherwise, it provides an error code and description. Clients should implement exponential backoff for failed requests: retry after an increasing wait time. The wait time is (2^n) + a random number of milliseconds, where 'n' starts at 0 and increments with each failed retry, up to 5. The process should terminate if errors persist after five retries. A Python code example implements this strategy using `HttpError`.\n"],null,["# Error Responses\n\nStandard Error Responses\n------------------------\n\nIf a Tag Manager API request is successful,\nthe API returns a `200` HTTP status code along with the\nrequested data in the body of the response.\n\nIf an error occurs with a request, the API returns an HTTP\nstatus code and reason in the response based on the type of error.\nAdditionally, the body of the response contains a detailed description\nof what caused the error. Here's an example of an error response: \n\n```\n400 invalidParameter\n\n{\n \"error\": {\n \"errors\": [\n {\n \"domain\": \"usageLimits\",\n \"reason\": \"accessNotConfigured\",\n \"message\": \"Access Not Configured. Please use Google Developers Console to activate the API for your project.\",\n }\n ],\n \"code\": 403,\n \"message\": \"Access Not Configured. Please use Google Developers Console to activate the API for your project.\"\n }\n}\n```\n\n**Note**: The description could change at any time\nso applications should not depend on the actual description text.\n\nImplementing Exponential Backoff\n--------------------------------\n\n[Exponential backoff](http://en.wikipedia.org/wiki/Exponential_backoff)\nis the process of a client periodically retrying a failed request over\nan increasing amount of time. It is a standard error handling strategy\nfor network applications. The Tag Manager API is designed with\nthe expectation that clients which choose to retry failed requests do\nso using exponential backoff. Besides being \"required\",\nusing exponential backoff increases the efficiency of bandwidth usage,\nreduces the number of requests required to get a successful\nresponse, and maximizes the throughput of requests in concurrent\nenvironments.\n\nThe flow for implementing simple exponential backoff is as follows.\n\n1. Make a request to the API.\n2. Receive an error response that has an error code that can be retried.\n3. Wait 1 second + `random_number_milliseconds` seconds.\n4. Retry request.\n5. Receive an error response that has an error code that can be retried.\n6. Wait 2 seconds + `random_number_milliseconds` seconds.\n7. Retry request.\n8. Receive an error response that has an error code that can be retried.\n9. Wait 4 seconds + `random_number_milliseconds` seconds.\n10. Retry request.\n11. Receive an error response that has an error code that can be retried.\n12. Wait 8 seconds + `random_number_milliseconds` seconds.\n13. Retry request.\n14. Receive an error response that has an error code that can be retried.\n15. Wait 16 seconds + `random_number_milliseconds` seconds.\n16. Retry request.\n17. If you still get an error, stop and log the error.\n\nIn the above flow, `random_number_milliseconds` is a random\nnumber of milliseconds less than or equal to 1,000. This is necessary\nto avoid certain lock errors in some concurrent implementations.\n`random_number_milliseconds` must be redefined after each wait.\n\n**Note** : The wait is always\n(2 \\^ *n* ) + `random_number_milliseconds`, where\n*n* is a monotonically increasing integer initially defined\nas 0. The variable *n* is incremented by 1 for each iteration\n(each request).\n\nThe algorithm is set to terminate when *n* is 5. This ceiling is\nin place only to stop clients from retrying infinitely, and\nresults in a total delay of around 32 seconds before a request\nis deemed \"an unrecoverable error.\"\n\nThe following Python code is an implementation of the above\nflow for recovering from errors that occur in a method called\n`makeRequest`. \n\n```python\nimport random\nimport time\nfrom apiclient.errors import HttpError\n\ndef makeRequestWithExponentialBackoff(tagmanager):\n \"\"\"Wrapper to request Google Tag Manager data with exponential backoff.\n\n The makeRequest method accepts the tagmanager service object, makes API\n requests and returns the response. If any error occurs, the makeRequest\n method is retried using exponential backoff.\n\n Args:\n tagmanager: The tagmanager service object\n\n Returns:\n The API response from the makeRequest method.\n \"\"\"\n for n in range(0, 5):\n try:\n return makeRequest(tagmanager)\n\n except HttpError, error:\n if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded']:\n time.sleep((2 ** n) + random.random())\n\n print \"There has been an error, the request never succeeded.\"\n```"]]
