REST API V2 チェックリスト

次の条件でポーリングメカニズムを起動します。

プライマリ（画面）アプリケーション内で認証を実行

• プライマリ（ストリーミング）アプリケーションでは、ブラウザーコンポーネントがセッションエンドポイントリクエストの「redirectUrl」パラメーターに指定された URL を読み込んだ後、ユーザーが最終的な宛先ページに到達すると、ポーリングを開始する必要があります。

セカンダリ（画面）アプリケーション内で実行される認証

• プライマリ（ストリーミング）アプリケーションでは、ユーザーが認証プロセスを開始するとすぐに、つまり、セッションエンドポイントの応答を受信して認証コードをユーザーに表示した直後に、ポーリングを開始する必要があります。

次の条件でポーリングメカニズムを停止します。

認証に成功

• ユーザーのプロファイル情報は正常に取得され、ユーザーの認証ステータスが確認されるので、ポーリングは不要になりました。

認証セッションとコードの有効期限

• 認証セッションとコードの有効期限が切れると、ユーザーは認証プロセスを再開する必要があり、以前の認証コードを使用したポーリングは直ちに停止する必要があります。

新しい認証コードが生成されました

• ユーザーが新しい認証コードを要求すると、既存のセッションが無効になり、前の認証コードを使用したポーリングがすぐに停止されます。

次の条件でポーリングメカニズムの頻度を設定します。

プライマリ（画面）アプリケーション内で認証が実行され す。

• プライマリ（ストリーミング）アプリケーションは、3 ～ 5 秒以上ごとにポーリングする必要があります。

セカンダリ（画面）アプリケーション内で実行される認証

• プライマリ（ストリーミング）アプリケーションは、3～5 秒ごとにポーリングする必要があります。

パフォーマンスを向上させ、不要な REST API v2 呼び出しを最小限に抑えるために、ユーザーのプロファイル情報の一部を永続ストレージに保存します。

キャッシュは、次のプロファイル応答フィールドに焦点を当てる必要があります：

mvpd

• クライアントアプリケーションは、これを使用してユーザーが選択したテレビプロバイダーを追跡し、事前認証または認証フェーズ中にさらに使用できます。
• 現在のユーザープロファイルの有効期限が切れると、クライアントアプリケーションは記憶されているMVPDの選択内容を使用し、ユーザーに確認を求めることができます。

属性

• 様々なユーザーメタデータキー（zip、maxRating など）に基づいてユーザーエクスペリエンスをパーソナライズするために使用されます。
• ユーザーメタデータは認証フローが完了すると使用できるようになります。したがって、ユーザーメタデータ情報は既にプロファイル情報に含まれているため、クライアントアプリケーションはユーザーメタデータ情報を取得するために別のエンドポイントをクエリする必要はありません。
• MVPD（Charter など）や特定のメタデータ属性（householdID など）に応じて、特定のメタデータ属性は認証フェーズ中に更新される場合があります。 その結果、最新のユーザーメタデータを取得するために、クライアントアプリケーションが認証後にプロファイル API を再度クエリする必要が生じる場合があります。

ログアウト API を実装して、ユーザーが手動でログアウトし、認証済みプロファイルを終了して、削除されたプロファイルごとに指定された REST API v2 アクション名に従えるようにします。

• ログアウトエンドポイントをサポートする MVPD の場合、クライアントアプリケーションは、ユーザーエージェントで指定された「url」に移動する必要があります。
• 「appleSSO」タイプのプロファイルの場合、クライアントアプリケーションは、パートナーレベル（Appleのシステム設定）からもログアウトするようにユーザーをガイドする必要があります。

公式のAdobe Pass認証非実稼動環境を使用して、アプリケーションを開発およびテストします。

• 前生産
• リリース – ステージング

リリース版の実稼働を開始する前に、これらの環境で徹底的な品質保証（QA）を実行します。

クライアントアプリケーションは、実稼動以外の環境で最初にエンドツーエンドの検証を完了しない限り、リリース実稼動に進んではなりません。

セカンダリ（2 番目）アプリケーション（画面）でユーザー入力を通じて送信された認証コードを検証してから、次の条件で/api/v2/authenticate API を呼び出します。

セカンダリ（画面）アプリケーション内で実行される認証で、事前に選択された mvpd を使用 ます。

• 認証セッションの再開を利用する – POST /api/v2/{serviceProvider}/sessions/{code}

事前に選択された mvpd を使用せずに、セカンダリ（画面）アプリケーション内で認証を実行

• 認証セッションの取得を利用する – GET /api/v2/{serviceProvider}/sessions/{code}

指定された認証コードが正しく入力されなかった場合、または認証セッションが期限切れになった場合、クライアントアプリケーションにエラーが発生します。

クライアントアプリケーションビジネスで必要とされる次のような場合に、非基本フローをサポートします。

• アクセス・フローの低下（プレミアム機能）
• 一時的なアクセスフロー（プレミアム機能）
• シングルサインオンアクセスフロー（標準機能）

デバイスとプラットフォームをまたいで、次の基本フローをテストします。

認証フロー

• プライマリアプリケーション（画面）認証のシナリオ
• セカンダリアプリケーション（画面）認証のシナリオ

（任意）事前認証フロー

• 許可の決定シナリオのテスト
• 拒否の決定シナリオのテスト

認証フロー

• 許可の決定シナリオのテスト
• 拒否の決定シナリオのテスト

ログアウトフロー

さらに、該当する場合は、他のアクセスフローをテストします。

• アクセス・フローの低下（プレミアム機能）
• 一時的なアクセスフロー（プレミアム機能）
• シングルサインオンアクセスフロー（標準機能）

上位のMVPD統合（最も広く使用されているプロバイダーをカバー）について説明します。