限制與配額
限制與配額可避免 Google 基礎架構自動執行 Reports API 的自動化程序。假如 API 發出過多要求,可能就產生無害的錯字,也可能是設計效率不佳、發出不必要的 API 呼叫的系統所導致。無論原因為何,在 Google Workspace 系統的整體健康狀態必須達到一定程度時,封鎖來自特定來源的流量。確保其中一個開發人員的行為不會對大型社群造成負面影響。
萬一 API 要求失敗,您就會收到 HTTP 狀態碼回應。狀態碼 403 包含錯誤輸入作業的相關錯誤資訊,HTTP 狀態碼 503 則包含錯誤訊息,指出已超出 API 配額。這些回應可讓您的自訂應用程式偵測這些錯誤,並採取適當行動。
如果需要在固定時間內完成要求,請同時傳送要求,或是在 Java 或 C# 應用程式中使用多個執行緒。舉例來說,同時要求不同使用者傳送的少數電子郵件便是同時要求他們傳送,而非同時新增或移除同一名使用者的電子郵件。如果是討論串,請嘗試從 10 個會話串開始,每個使用者電子郵件一個會話串。請注意,執行緒建議有權衡取捨,不適合所有 API 情況。如果要求數量過高,就會發生配額錯誤。
針對所有基於時間的錯誤 (每個執行緒最多 N 次,每個執行緒最多 N 個錯誤),特別是 503 狀態碼錯誤,建議您使用程式碼擷取例外狀況,然後使用指數輪詢演算法,等待短暫延遲,然後再重試失敗的呼叫。一個執行緒的 Reports API 範例是等待 5 秒,然後重試失敗的呼叫。如果要求成功,請為其他執行緒重複這個模式。如果第二個要求並未成功,應用程式應縮減要求的頻率,直到呼叫成功為止。舉例來說,您可以將初始的 5 秒延遲時間延長至 10 秒,然後再次重試失敗的呼叫。此外,請決定重試限制。舉例來說,假設在應用程式向使用者傳回錯誤前,會先重試 5 到 7 次,且延遲時間各不相同。
API 限制類別 |
限制 |
回報 QPS 和 QPD 費率 |
API 會限制 Google Cloud 專案的要求數量。在 Google Cloud 控制台中設定的預設值是每項 Google Cloud 專案每位使用者每分鐘 2,400 次查詢。
如要提高這項限制,請前往 Google Cloud 專案的 Admin SDK API 配額頁面。 如果超過這些限制,伺服器會傳回 HTTP 503 狀態碼。重試要求時,請使用指數輪詢演算法。
|
API 配額類別 |
配額 |
最大結果 |
API 回應中每一頁列出的記錄數量都是 1 到 1000 個事件。預設值為 1000 筆記錄。 |
其他限制類型 |
限制與規範 |
資料格式 (預設) |
預設資料格式為 JSON,這個 API 也支援 Atom 格式。
|
未授權請求 |
Google 不允許未經授權的 API 要求。如未提供授權權杖,系統會將該要求視為未授權。詳情請參閱「授權要求」。 |
警告訊息 |
- 無可用資料:無法取得此應用程式和日期的資料,日後無法再提供。
- 尚未提供部分資料:此應用程式和此日期的資料未來可能會開放使用。
如要瞭解 Reports API 的警告語法,請參閱「客戶」和「使用者」專用的 API 參考資料。 |
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2024-08-29 (世界標準時間)。
[null,null,["上次更新時間:2024-08-29 (世界標準時間)。"],[[["The Reports API has limits and quotas in place to protect Google infrastructure and ensure fair usage for all users."],["API requests might fail with specific HTTP status codes like 403 or 503, indicating input errors or quota exceedances, respectively, which your application should handle."],["To optimize performance, consider using parallel requests or multithreading, but be mindful of potential quota issues with excessive requests."],["Implement exponential backoff when encountering time-based errors to avoid overwhelming the system, gradually increasing delay intervals between retries."],["Familiarize yourself with specific API limits, including query rates, result sizes, and data formats, to design your application for optimal functionality within these constraints."]]],[]]