[null,null,["上次更新時間：2025-08-29 (世界標準時間)。"],[[["\u003cp\u003eAll requests to the Google Photos Library API require authorization from an authenticated user using OAuth 2.0, involving registration, scope definition, user consent, and access token retrieval.\u003c/p\u003e\n"],["\u003cp\u003eTo maintain data freshness, avoid caching media for over 60 minutes, refresh \u003ccode\u003ebaseUrls\u003c/code\u003e regularly, and utilize media/album IDs for persistent storage, potentially leveraging search parameters for efficient bulk updates.\u003c/p\u003e\n"],["\u003cp\u003eAll Library API requests must use HTTPS through the specified URL; HTTP requests will be rejected, and error handling follows Cloud API guidelines with specific retry strategies for certain error codes.\u003c/p\u003e\n"],["\u003cp\u003eClients should implement exponential backoff for \u003ccode\u003e5xx\u003c/code\u003e errors and employ strategies like randomized alarms to avoid synchronized requests, ensuring polite API usage and preventing potential service disruptions.\u003c/p\u003e\n"]]],["To use the Google Photos Library API, applications must be authorized via OAuth 2.0. This involves registering the application, requesting access scopes, and obtaining an access token upon user consent. Data caching is limited to 60 minutes, excluding media and album IDs. All API requests must use HTTPS. Implement error handling and retry `5xx` errors with exponential backoff (minimum 1s) and `429` errors with a minimum 30s delay. Avoid synchronized requests to prevent excessive load.\n"],null,["# Best practices\n\nAuthorization\n-------------\n\nAll requests to the Google Photos Library API 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 Library API and retrieve OAuth details such as a client ID and a client secret. For more information, see [Get started](/photos/library/legacy/guides/get-started).\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/library/legacy/guides/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\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/legacy/guides/access-media-items#get-media-item) or [Listing\nalbums](/photos/library/legacy/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 Library API 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."]]
