本頁面列出您可能會從 User Deletion API 收到的錯誤，並說明如何處理 500 錯誤和實作指數輪詢。
標準錯誤回應
如果使用者刪除 API 要求成功，API 會傳回 200 狀態碼。如果要求發生錯誤，API 會根據錯誤類型，在回應中傳回 HTTP 狀態碼、狀態和原因。此外，回應主體會詳細說明導致錯誤的原因。以下是錯誤回應範例：
{ "error": { "errors": [ { "domain": "global", "reason": "invalidParameter",
"message": "Invalid value '-1' for max-results. Value must be within the range:
[1, 1000]", "locationType": "parameter", "location": "max-results" } ], "code":
400, "message": "Invalid value '-1' for max-results. Value must be within the
range: [1, 1000]" } }
錯誤表格
| 程式碼 | 原因 | 說明 | 建議做法 |
|---|---|---|---|
| 400 | invalidParameter |
表示要求參數有一個無效值。錯誤回應中的 locationType 和 location 欄位會提供無效值的相關資訊。 |
未修正問題前請勿重試。您必須為錯誤回應中指定的參數提供有效的值。 |
| 400 | badRequest |
表示查詢無效。例如，缺少父項 ID，或是要求的維度或指標組合無效。 | 未修正問題前請勿重試。您必須修改 API 查詢，才能正常運作。 |
| 401 | invalidCredentials |
表示驗證權杖無效或已過期。 | 未修正問題前請勿重試。您需要取得新的授權權杖。 |
| 403 | insufficientPermissions |
表示使用者對查詢中指定的實體沒有足夠的權限。 | 未修正問題前請勿重試。您必須取得足夠的權限，才能對指定實體執行作業。 |
| 403 | dailyLimitExceeded |
表示使用者已超過每日配額 (每項專案或每項資料檢視 (設定檔))。 | 未修正問題前請勿重試。您已用盡每日配額。請參閱「API 限制與配額」。 |
| 403 | userRateLimitExceeded |
表示已超過每位使用者每 100 秒的查詢數限制。Google API 控制台的預設值為每位使用者每 100 秒 100 個查詢。您可以在 Google API 控制台中提高這個限制，上限為 1,000 個。 | 使用指數輪詢重試。您需要放慢傳送要求的速度。 |
| 403 | rateLimitExceeded |
表示專案每 100 秒的查詢次數頻率已超過上限。 | 使用指數輪詢重試。您需要放慢傳送要求的速度。 |
| 403 | quotaExceeded |
表示已達到 Core Reporting API 中每個檢視畫面 (設定檔) 的 10 個並行要求上限。 | 使用指數輪詢重試。您必須等待這個檢視畫面 (設定檔) 至少有一個進行中的要求完成。 |
| 500 | internalServerError |
發生未預期的內部伺服器錯誤。 | 這項查詢最多只能重試一次。 |
| 503 | backendError |
伺服器傳回錯誤。 | 這項查詢最多只能重試一次。 |
處理 500 或 503 回應
在負載或大型複雜要求期間，可能會發生 500 或 503 錯誤。針對較大型的要求，請考慮要求較短的時間範圍。您也可以考慮實施指數輪詢。這些錯誤的發生頻率可能取決於檢視畫面 (設定檔) 和與該檢視畫面相關聯的報表資料量；如果某個查詢會導致某個檢視畫面 (設定檔) 發生 500 或 503 錯誤，不一定會導致使用不同檢視畫面 (設定檔) 的相同查詢發生錯誤。
實作指數輪詢
指數輪詢是指用戶端定期重試失敗的要求，並逐漸增加重試次數的過程。這是網路應用程式的標準錯誤處理策略設計 User Deletion 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。
演算法已設定為會在 n 等於 5 時終止。這個上限只會防止用戶端一直重試下去，導致要求在總延遲時間達到約 32 秒之後，才會被視為「無法復原的錯誤」。
下列 Python 程式碼實作上述流程，可從發生在 makeRequest 方法中的錯誤中復原。
import random
import time
from apiclient.errors import HttpError
def makeRequestWithExponentialBackoff(analytics):
"""Wrapper to request Google Analytics data with exponential backoff.
The makeRequest method accepts the analytics service object, makes API
requests and returns the response. If any error occurs, the makeRequest
method is retried using exponential backoff.
Args:
analytics: The analytics service object
Returns:
The API response from the makeRequest method.
"""
for n in range(0, 5):
try:
return makeRequest(analytics)
except HttpError, error:
if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded',
'internalServerError', 'backendError']:
time.sleep((2 ** n) + random.random())
else:
break
print "There has been an error, the request never succeeded."