授權
所有向 Google Photos Library API 發出的要求都必須獲得已驗證使用者的授權。
OAuth 2.0 授權程序的細節會稍有不同 處理要編寫的應用程式類型下列一般程序 適用於所有應用程式類型：
- 請按照下列步驟操作，準備授權程序：
- 使用 Google API 控制台。
- 啟用 Library API 並擷取 OAuth 詳細資料，例如 用戶端 ID 和用戶端密鑰。若需更多資訊，請參閲 立即開始使用。
- 如要存取使用者資料，應用程式會向 Google 要求 與存取範圍有關
- Google 會向使用者顯示同意畫面，請他們授權 應用程式並要求其部分資料。
- 使用者核准後，Google 就會提供應用程式 並在隨後的極短時間內失效
- 應用程式針對使用者資料發出要求，並附上存取權杖 加到要求中
- 如果 Google 判定請求和權杖有效，就會傳回 要求的資料
如要判斷哪些範圍適用於應用程式，請參閱授權 範圍。
部分應用程式類型的流程包含額外步驟，例如使用 更新權杖，取得新的存取權杖。如要進一步瞭解 請參閱使用 OAuth 2.0 存取 Google API
快取
即時更新資料。
如果您需要暫時儲存媒體 (例如縮圖、相片或影片) 基於效能考量，每次使用資料時請勿快取超過 60 分鐘 準則。
此外，也不應儲存 baseUrls，後者會在約 60 後過期
分鐘。
用於識別使用者媒體庫內容的媒體項目 ID 和專輯 ID 不必受限於快取限制。您可以無限期儲存這些 ID (以應用程式的隱私權政策為準)。使用媒體項目 ID 和專輯 ID ，再次使用適當的端點擷取可存取的網址和資料。適用對象 詳情請參閱取得媒體 item 或 Listing 相簿。
如果您有許多要重新整理的媒體項目，以最有效率的方式儲存 搜尋參數，並重新提交查詢以重新載入媒體項目 資料。
SSL 存取
所有使用 下列網址：
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 呼叫不會延遲轉譯作業。
除了每分每秒 不要將目標設為開始時間 每天午夜。