授權
所有向 Google 相簿 API 發出的要求都必須獲得已驗證使用者的授權。
OAuth 2.0 授權程序的細節會根據您編寫的應用程式類型而略有不同。下列一般程序適用於所有應用程式類型：
- 請按照下列步驟準備授權程序：
- 使用 Google API 控制台註冊應用程式。
- 啟用相片 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 傳回的錯誤，請參閱「處理錯誤」一文。
重試失敗的要求
用戶端應在發生 5xx 錯誤時以指數輪詢的方式重試，如「指數輪詢」一節所述。除非另有說明，否則最短延遲時間應為 1 s。
如果是 429 錯誤，用戶端重試的最短延遲時間可為 30s。對於所有其他錯誤，重試可能不適用。請確認要求是冪等的，然後查看錯誤訊息以取得相關指示。
指數輪詢
在極少數情況下，系統可能會在處理要求時發生錯誤。您可能會收到 4XX 或 5XX HTTP 回應碼，或是在用戶端和 Google 伺服器之間的某個位置發生 TCP 連線失敗。通常，重試要求是值得的。原始要求失敗時，後續要求可能會成功。不過，請勿重複循環，不斷向 Google 伺服器提出要求。這種迴圈行為可能會導致用戶端與 Google 之間的網路過載，並對許多使用者造成問題。
較好的做法是重試，並在每次重試之間增加延遲時間。通常，每次嘗試時，延遲時間都會乘以一個係數，這種做法稱為「指數輪詢」。
您也應小心，避免在應用程式呼叫鏈結中加入重試程式碼，導致重複要求快速接續。
禮貌使用 Google API
設計不良的 API 用戶端可能會在網路和 Google 伺服器上造成不必要的負載。本節將說明 API 用戶端的部分最佳做法。遵循這些最佳做法，有助於避免應用程式因誤用 API 而遭到封鎖。
同步要求
大量同步至 Google API 的同步要求可能會被視為對 Google 基礎架構發動的分散式阻斷服務 (DDoS) 攻擊，並受到相應的處理。為避免這種情況，請確認 API 要求不會在用戶端之間同步處理。
舉例來說，假設應用程式會顯示目前時區的時間。這個應用程式可能會在用戶端作業系統中設定鬧鐘，在分鐘開始時喚醒它，以便更新顯示的時間。應用程式不應在與該鬧鐘相關的處理程序中呼叫任何 API。
針對固定鬧鐘發出 API 呼叫是不好的做法，因為這會導致 API 呼叫同步至分鐘的開始時間，甚至在不同裝置之間同步，而非在一段時間內平均分配。設計不良的應用程式會在每分鐘的開始時，產生流量尖峰，其程度是正常流量的六十倍。
相反地，一個可能的良好設計是將第二個鬧鐘設為隨機選擇的時間。當第二個鬧鐘觸發時，應用程式會呼叫所需的任何 API，並儲存結果。為了在分鐘開始時更新顯示內容，應用程式會使用先前儲存的結果，而不是再次呼叫 API。採用這種做法，API 呼叫會在一段時間內平均分散。此外，API 呼叫不會在螢幕更新時延遲轉譯。
除了分鐘開始時間之外，您也應避免在其他常見的同步時間 (例如每小時開始時間和每天午夜開始時間) 指定目標。