おすすめの方法

承認

Google Photos Library API へのすべてのリクエストは、認証済みのユーザーによって承認される必要があります。

OAuth 2.0 の承認プロセスの詳細は、 作成中のアプリケーションの種類に応じて 異なる可能性があります一般的なプロセスは次のとおりです。 次のすべての種類のアプリケーションに適用されます。

  1. 以下を実施して、承認プロセスの準備をします。 <ph type="x-smartling-placeholder">
      </ph>
    • 次を使用してアプリケーションを登録する: Google API Console:
    • Library API を有効にして、 クライアント シークレットが含まれています。詳細については、次をご覧ください: 使ってみる
  2. ユーザーデータにアクセスするために、アプリケーションは Google に 付与できます。
  3. Google は、 アプリケーションにデータを要求します。
  4. ユーザーが承認すると、Google はアプリケーションにアクセス トークンを付与する 短期間で期限切れとなるデータです
  5. アプリケーションがユーザーデータをリクエストし、アクセス トークンが付加される 渡します。
  6. Google がリクエストとトークンが有効であると判断すると、 必要があります。

アプリケーションに適したスコープを判断するには、認可 スコープ。

アプリケーションの種類によっては、このプロセスに追加の手順（ 更新トークンを使用して新しいアクセス トークンを取得します。このモジュールで のフローについて、詳しくは OAuth 2.0 を使用した Google Cloud へのアクセス API。

キャッシュ

データを最新の状態に保つ。

メディア（サムネイル、写真、動画など）を一時的に保存する必要がある場合 パフォーマンス上の理由から、60 分以上はキャッシュに保存しないでください。 確認してください。

また、約 60 後に期限切れになる baseUrls も保存しないでください。 できます。

ユーザーのライブラリ内のコンテンツを一意に識別するメディア アイテム ID とアルバム ID キャッシュの制限が免除されます。これらの ID は無期限に保存できます。 （アプリのプライバシー ポリシーによります）。メディア アイテム ID とアルバム ID を使用する 適切なエンドポイントを使用して、アクセス可能な URL とデータを再度取得します。対象 詳しくは、メディアを取得する 商品アイテムまたはリスティング できます。

更新するメディア アイテムが多数ある場合は、 メディア アイテムを返したパラメータを検索し、クエリを再送信して再読み込みしてください 分析できます

SSL アクセス

すべての Library API ウェブサービス リクエストでは、 できます。

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 のサーバー上にあることですこのセクションでは、Google Cloud で API のクライアントですこれらのベスト プラクティスに従うことで、 API の意図しない不正使用によりブロックされたアプリケーション。

同期リクエスト

Google の API への多数の同期リクエストは、 Google のインフラストラクチャに対する分散型サービス拒否（DDoS）攻撃。 適切に扱われますこれを回避するには、API リクエストが Cloud Logging に クライアント間では同期されません

たとえば、現在の時刻の時刻を表示するアプリケーションについて考えてみましょう。 設定されます。このアプリケーションはおそらく、クライアント オペレーティング システムでアラームを設定します。 時刻表示ができるように、毎分 0 秒にスリープ状態から 更新しました。処理の一環としてアプリケーションが API 呼び出しを行わない 表示されます。

固定されたアラームに応答して API 呼び出しを行うと、 API 呼び出しは、開始時刻と終了時刻の間で同期します。異なる時間の間でも 時間とともに均等に分散されるのではなく、不適切な設計 通常の 60 倍のレベルでトラフィックが急増します。 表示されます。

その代わりに、2 つ目のアラームをランダムに設定し、 表示されます。この 2 番目のアラームを起動すると、アプリケーションは 結果を保存します。イベントの開始時に表示を更新するには、 その分だけ保存されると、アプリケーションは API を再度呼び出します。このアプローチでは、API 呼び出しが時間の経過とともに均等に分散されます。さらに、 ディスプレイが更新されても、API 呼び出しによってレンダリングが遅延することはありません。

毎分 1, 000 文字を超える一般的な同期時刻のほか、 開始時刻と終了時刻を 毎日午前 0 時に行われます