授權
所有傳送至 Google Photos API 的要求都必須獲得已驗證使用者的授權。
OAuth 2.0 授權程序的細節會稍有不同 請進行效能檢查下列一般程序 適用於所有應用程式類型：
- 請按照下列步驟操作，準備授權程序：
- 使用 Google API 控制台註冊應用程式。
- 啟用 Photos API 並擷取 OAuth 詳細資料，例如 用戶端 ID 和用戶端密鑰。詳情請參閱入門指南。
- 為了存取使用者資料，應用程式會向 Google 要求特定的存取範圍。
- Google 會向使用者顯示同意畫面，請他們授權 應用程式並要求其部分資料。
- 使用者核准後，Google 就會提供應用程式 並在隨後的極短時間內失效
- 應用程式會要求使用者資料，並且在要求中附上存取權杖。
- 如果 Google 判定請求和權杖有效，就會傳回 要求的資料
如要判斷哪些範圍適合您的應用程式，請參閱「授權範圍」。
部分應用程式類型的流程包含額外步驟，例如使用 更新權杖，取得新的存取權杖。如要進一步瞭解 請參閱使用 OAuth 2.0 存取 Google API
快取
持續更新資料。
如果您基於效能考量而需要暫時儲存媒體 (例如縮圖、相片或影片)，請根據我們的使用指南，將其快取時間控制在 60 分鐘以內。
您也不應儲存 baseUrls，因為這會在約 60 分鐘後到期。
媒體項目 ID 和專輯 ID 可用於識別使用者媒體庫中的內容，因此不受快取限制的約束。您可以無限期儲存這些 ID (視應用程式的隱私權政策而定)。使用媒體項目 ID 和專輯 ID，透過適當的端點再次擷取可存取的網址和資料。詳情請參閱「取得媒體項目」或「列出專輯」。
如果您需要重新整理的媒體項目很多，建議您儲存傳回媒體項目的搜尋參數，然後重新提交查詢，以便重新載入資料，這樣可能會更有效率。
SSL 存取
使用下列網址的所有 Google 相簿 API 網路服務要求都必須透過 HTTPS 傳送：
https://photoslibrary.googleapis.com/v1/service/output?parameters
透過 HTTP 發出的要求會遭到拒絕。
處理錯誤
如要瞭解如何處理 API 傳回的錯誤，請參閱 API 處理 錯誤。
重試失敗的要求
用戶端應在發生 5xx 錯誤時以指數輪詢的方式重試，詳情請參閱
指數輪詢。最短延遲時間應為 1 s
除非另有說明
如果是 429 錯誤，用戶端重試的最短延遲時間可為 30s。對於所有其他錯誤，重試可能不適用。請確認您的要求為冪等，並查看
錯誤訊息。
指數輪詢
在極少數的情況下，處理要求時可能發生錯誤。您可能會收到
4XX 或 5XX HTTP 回應代碼，或是 TCP 連線在某處失敗
讓用戶端和 Google 伺服器相互通訊通常，重試要求是值得的。如果原始要求失敗，後續追蹤要求可能會成功。不過，請勿重複循環，不斷向 Google 伺服器提出要求。這種迴圈行為可能會導致用戶端與 Google 之間的網路過載，並對許多使用者造成問題。
更好的做法是，每次嘗試間持續增加延遲。這些廣告活動 每次嘗試時延遲時間都會增加 稱為指數型 Backoff。
您也應小心，避免在應用程式呼叫鏈結中加入重試程式碼，導致重複要求快速接續。
禮貌使用 Google API
設計不良的 API 用戶端，可能會佔用過多 網際網路和 Google 伺服器本節將說明 API 用戶端的部分最佳做法。遵循這些最佳做法，有助於避免應用程式因誤用 API 而遭到封鎖。
同步要求
大量同步至 Google API 的同步要求可能會被視為對 Google 基礎架構發動的分散式阻斷服務 (DDoS) 攻擊，並受到相應的處理。為避免這種情況，請確認 API 要求不會在用戶端之間同步處理。
舉例來說，假設應用程式會顯示目前時區的時間。這個應用程式可能會在用戶端作業系統上設定鬧鐘 在該分鐘開始時喚醒裝置，以便可以 已更新。應用程式不應在處理程序中發出任何 API 呼叫 與該鬧鐘相關聯的名稱
針對固定鬧鐘發出 API 呼叫是不好的做法，因為這會導致 API 呼叫同步至分鐘的開始時間，甚至在不同裝置之間同步，而非在一段時間內平均分配。設計不佳 會產生大量流量 尖峰至正常範圍 60 倍 每分鐘的開始
相反的，可以考慮將第二個鬧鐘隨機設定 當第二個鬧鐘觸發時，應用程式會呼叫任何 並儲存結果如要在 1 分鐘，應用程式會使用先前儲存的結果，而不會呼叫 API。採用這種做法，API 呼叫會在一段時間內平均分散。另外 顯示畫面更新時，API 呼叫不會延遲轉譯作業。
除了分鐘開始時間之外，您也應避免在其他常見的同步處理時間 (例如小時開始時間和每天午夜開始時間) 指定目標。