在极少数情况下，您的请求可能会在传送时出错。您可能会收到 4XX 或 5XX HTTP 响应代码，或者 TCP 连接可能会在客户端与 Google 服务器之间的某处出现错误。通常情况下，重试请求值得一试。首次请求失败后，后续请求可能会成功。但是，切勿进行循环操作，即反复向 Google 服务器发出请求。这种循环行为可能会使客户端与 Google 之间的网络过载，给多方造成问题。
[null,null,["最后更新时间 (UTC)：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."]]
