在極少數的情況下，處理要求時可能發生錯誤。您可能會收到
4XX 或 5XX HTTP 回應代碼，或是 TCP 連線在某處失敗
讓用戶端和 Google 伺服器相互通訊通常，重試要求是值得的。如果原始要求失敗，後續追蹤要求可能會成功。不過，請勿重複循環，不斷向 Google 伺服器提出要求。這種迴圈行為可能會導致用戶端與 Google 之間的網路過載，並對許多使用者造成問題。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-08-29 (世界標準時間)。"],[[["\u003cp\u003eAll requests to the Google Photos API must be authorized by an authenticated user using OAuth 2.0, requiring application registration and user consent.\u003c/p\u003e\n"],["\u003cp\u003eFor the Library API, temporarily stored media like thumbnails or photos shouldn't be cached for longer than 60 minutes, while media and album IDs can be stored indefinitely.\u003c/p\u003e\n"],["\u003cp\u003eAll Photos API requests must use HTTPS through the specified URL, with HTTP requests being rejected.\u003c/p\u003e\n"],["\u003cp\u003eImplement error handling and retry failed requests with exponential backoff, adjusting delays based on the error code.\u003c/p\u003e\n"],["\u003cp\u003eDesign API clients to avoid synchronized requests that could overload Google's servers, utilizing strategies like randomized alarms to distribute calls evenly over time.\u003c/p\u003e\n"]]],["To use Google Photos APIs, applications must register via the Google API Console and obtain OAuth credentials. Applications request user data by obtaining an access token through a user consent process, which is then attached to API requests. Caching of media is limited to 60 minutes, but media/album IDs can be stored indefinitely. All API requests must use HTTPS, and clients should retry `5xx` errors with exponential backoff and `429` errors after a 30-second delay. Avoid synchronized API requests to prevent overloading Google's servers.\n"],null,["# Best practices\n\n| **Note:** This page focuses on technical best practices for optimal Photos API usage. For information on API policies and guidelines, refer [Photos API User Data and Developer Policy](/photos/support/api-policy).\n\nAuthorization\n-------------\n\nAll requests to the Google Photos APIs must be authorized by an authenticated user.\n\nThe details of the authorization process for OAuth 2.0 vary slightly depending\non what kind of application you're writing. The following general process\napplies to all application types:\n\n1. Prepare for the authorization process by doing the following:\n - Register your application using the [Google API Console](https://console.developers.google.com/).\n - Activate the Photos APIs and retrieve OAuth details such as a client ID and a client secret. For more information, see [Get started](/photos/overview/configure-your-app).\n2. To access user data, the application makes a request to Google for a particular scope of access.\n3. Google displays a consent screen to the user which asks them to authorize the application to request some of their data.\n4. If the user approves, Google provides the application with an access token that expires after a brief period of time.\n5. The application makes a request for the user data, attaching the access token to the request.\n6. If Google determines that the request and the token are valid, it returns the requested data.\n\nTo determine what scopes are suitable for your application, see [Authorization\nscopes](/photos/overview/authorization).\n\nThe process for some application types includes additional steps, such as using\nrefresh tokens to acquire new access tokens. For detailed information about\nflows for various types of applications, see [Using OAuth 2.0 to Access Google\nAPIs](/identity/protocols/OAuth2).\n| **Note:** Given the security implications of getting the implementation correct, we strongly encourage you to use OAuth 2.0 libraries when interacting with Google's OAuth 2.0 endpoints. It's a best practice to use well-debugged code provided by others, and it helps you protect yourself and your users. For more information, see [OAuth 2.0 Client libraries](/identity/protocols/OAuth2#libraries).\n\nCaching\n-------\n\n| **Note:** For the Library API only\n\nKeep data fresh.\n\nIf you need to temporarily store media (such as thumbnails, photos, or videos)\nfor performance reasons, don't cache it for longer than 60 minutes per our usage\nguidelines.\n\nYou also shouldn't store `baseUrls`, which expire after approximately 60\nminutes.\n\nMedia item IDs and album IDs that uniquely identify content in a user's library\nare exempt from the caching restriction. You can store these IDs indefinitely\n(subject to your application's privacy policy). Use media item IDs and album IDs\nto retrieve accessible URLs and data again using the appropriate endpoints. For\nmore information, see [Get a media\nitem](/photos/library/guides/access-media-items#get-media-item) or [Listing\nalbums](/photos/library/guides/list#listing-albums).\n\nIf you have many media items to refresh, it might be more efficient to store the\nsearch parameters that returned the media items and resubmit the query to reload\ndata.\n\nSSL access\n----------\n\nHTTPS is required for all Photos APIs web service requests using the\nfollowing URL: \n\n```\nhttps://photoslibrary.googleapis.com/v1/service/output?parameters\n```\n\nRequests made over HTTP are rejected.\n\nError handling\n--------------\n\nFor information regarding how to handle errors returned from the API, see Cloud\nAPIs [Handling\nerrors](https://cloud.google.com/apis/design/errors#handling_errors).\n\n### Retrying failed requests\n\nClients should retry on `5xx` errors with exponential backoff as described in\n[Exponential backoff](#exponential-backoff). The minimum delay should be `1 s`\nunless otherwise documented.\n\nFor `429` errors, the client may retry with minimum `30s` delay. For all other\nerrors, retry may not be applicable. Ensure your request is idempotent and see\nthe error message for guidance.\n\n### Exponential backoff\n\nIn rare cases, something may go wrong serving your request.You may receive a\n`4XX` or `5XX` HTTP response code, or the TCP connection may fail somewhere\nbetween your client and Google's server. Often, it's worthwhile to retry the\nrequest. The follow up request may succeed when the original failed. However,\nit's important to not loop, repeatedly making requests to Google's servers. This\nlooping behavior can overload the network between your client and Google and\ncause problems for many parties.\n\nA better approach is to retry with increasing delays between attempts. Usually,\nthe delay is increased by a multiplicative factor with each attempt, an approach\nknown as [Exponential\nbackoff](https://en.wikipedia.org/wiki/Exponential_backoff).\n\nYou should also be careful that there isn't retry code higher in the application\ncall chain that leads to repeated requests in quick succession.\n\nPolite use of Google APIs\n-------------------------\n\nPoorly designed API clients can place more load than necessary on both the\ninternet and on Google's servers. This section contains some best practices for\nclients of the APIs. Following these best practices can help you avoid your\napplication being blocked for inadvertent abuse of the APIs.\n\n### Synchronized requests\n\nLarge numbers of synchronized requests to Google's APIs can look like a\nDistributed Denial of Service (DDoS) attack on Google's infrastructure, and be\ntreated accordingly. To avoid this, you should make sure that API requests are\nnot synchronized between clients.\n\nFor example, consider an application that displays the time in the current time\nzone. This application will probably set an alarm in the client operating system\nwaking it up at the start of the minute so that the displayed time can be\nupdated. The application shouldn't make any API calls as part of the processing\nassociated with that alarm.\n\nMaking API calls in response to a fixed alarm is bad because it results in the\nAPI calls being synchronized to the start of the minute, even between different\ndevices, rather than being distributed evenly over time. A poorly designed\napplication doing this produces a spike of traffic at sixty times normal levels\nat the start of each minute.\n\nInstead, one possible good design is to have a second alarm set to a randomly\nchosen time. When this second alarm fires, the application makes calls to any\nAPIs it needs and stores the results. To update its display at the start of the\nminute, the application uses previously stored results rather than calling the\nAPI again. With this approach, API calls are spread evenly over time. Further,\nthe API calls don't delay rendering when the display is being updated.\n\nAside from the start of the minute, other common synchronization times you\nshould be careful to not target are at the start of an hour and the start of\neach day at midnight."]]
