おすすめの方法

承認

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

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

以下を実施して、承認プロセスの準備をします。 <ph type="x-smartling-placeholder">
- 次を使用してアプリケーションを登録する: Google API Console:
- Photos API を有効にして、クライアント ID やクライアントシークレットなどの OAuth の詳細を取得します。詳細については、スタートガイドをご覧ください。
ユーザーデータにアクセスするために、アプリケーションは Google に付与できます。
Google はユーザーに同意画面を表示します。ユーザーはこの画面で、アプリケーションが一部のユーザーデータをリクエストできるように承認を求められます。
ユーザーが承認すると、Google はアプリケーションにアクセストークンを付与する短期間で期限切れとなるデータです
アプリケーションがユーザーデータをリクエストし、アクセストークンが付加される渡します。
リクエストとトークンが有効であると判断されると、リクエストしたデータが返されます。

アプリケーションに適したスコープを判断するには、承認スコープをご覧ください。

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

キャッシュ

データを最新の状態に維持しましょう。

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

また、約 60 分経過すると期限が切れる baseUrls も保存しないでください。

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

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

SSL アクセス

次の URL を使用するすべての Photos 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 への多数の同期リクエストは、分散型サービス拒否（DDoS）攻撃によって、Google のインフラストラクチャが適切に扱われますこれを回避するには、API リクエストが Cloud Logging にクライアント間では同期されません

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

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

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

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