授权
向 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，通过适当的端点再次检索可访问的网址和数据。如需了解详情，请参阅获取媒体内容或列出影集。
如果您要刷新多项媒体内容，则更高效的做法可能是存储返回媒体内容的搜索参数，并重新提交查询以重新加载数据。
SSL 访问
使用以下网址的所有 Library API 网络服务请求都需要 HTTPS 协议：
https://photoslibrary.googleapis.com/v1/service/output?parameters
通过 HTTP 发出的请求会被拒绝。
错误处理
如需了解如何处理 API 返回的错误，请参阅 Cloud API 处理错误。
重试失败的请求
如指数退避算法中所述，客户端应在出现 5xx 错误时使用指数退避算法重试。除非另有说明，否则最小延迟应为 1 s。
对于 429 错误，客户端可能会以最小 30s 的延迟重试。对于所有其他错误，重试可能不适用。请确保您的请求具有幂等性，并查看错误消息以获取指导。
指数退避算法
在极少数情况下，系统在处理您的请求时会出错。您可能会收到 4XX 或 5XX HTTP 响应代码，或者 TCP 连接在您的客户端与 Google 服务器之间的某处可能会失败。通常，重试请求是值得的。初始请求失败时，后续请求可能会成功。但是，切记不要进行循环操作，反复向 Google 的服务器发出请求。这种循环行为可能会使客户端和 Google 之间的网络过载，从而给多方造成问题。
一种更好的方法是增加两次尝试之间的延迟，然后再重试。通常，每次尝试时，延迟时间都会按乘法系数增加，这种方法称为指数退避算法。
您还应注意，应用调用链中没有更高层级的重试代码，可导致快速连续的重复请求。
合理使用 Google API
设计不佳的 API 客户端可能会给互联网和 Google 服务器上造成超出必要负载的负载。本部分包含适用于 API 客户端的一些最佳实践。遵循这些最佳实践有助于避免您的应用因无意中滥用 API 而遭到屏蔽。
同步请求
针对 Google API 的大量同步请求看起来就像是针对 Google 基础架构的分布式拒绝服务 (DDoS) 攻击，需要相应的处理。为避免这种情况，您应确保 API 请求不会在客户端之间同步。
例如，假设某个应用显示当前时区的时间。此应用可能会在客户端操作系统中设置闹钟，并在分钟开始时将其唤醒，以便更新显示的时间。在与该闹钟相关的处理过程中，应用不应发出任何 API 调用。
进行 API 调用来响应固定闹钟是不好的做法，因为这会导致 API 调用同步到分钟的开始时间（即使在不同设备之间也是如此），而不是随时间均匀分布。如果一个设计不当的应用这样做，则会在每分钟开始时产生正常水平的 60 倍的流量高峰。
相反，一种可能的良好设计是将第二个闹钟设置为随机选择的时间。当第二个闹钟触发时，应用会调用所需的任何 API 并存储结果。为了在分钟开始时更新其显示内容，应用会使用之前存储的结果，而不是再次调用该 API。通过这种方法，API 调用会在一段时间内均匀分布。此外，在更新显示画面时，API 调用不会延迟渲染。
除了分钟开始之外，您应注意不要设置的其他常见同步时间包括小时开始和每天开始时间（午夜）。