アクション センターが販売者に代わって予約を作成、更新するコールバックを行うには、予約サーバーが必要です。これにより、アクション センターはユーザーに代わって予約を作成できます。
サンドボックスと本番環境の予約 サーバーへの接続を設定する方法については、 予約サーバーの認証情報を設定するをご覧ください。
リアルタイム更新に移行する前に、予約サーバーの準備完了に関する次のタスクを完了してください。
- BatchAvailabilityLookup ページの読み込みの準備完了
- BatchAvailabilityLookup スロットのクリックの準備完了
- CreateBooking の準備完了
- UpdateBooking の準備完了
- [空き状況チェッカーを有効にする] アクション センターの [設定] [アカウント機能]
サンドボックスの予約フローを通じて、正確なリアルタイムの在庫詳細情報を予約サーバーのリクエストに送信すると、各タスクが完了としてマークされ、緑色に変わります。 予約サーバーのマイルストーンは 14 日間にわたって分析されます。
REST API インターフェースを実装する
REST に基づいて API インターフェースを実装します。これにより、Google は HTTPS 経由で予約サーバーのリクエストを送信できます。
API インターフェースを実装するには、アクション センターのサンドボックス環境に接続する開発用またはサンドボックス用の予約サーバーを設定します。本番環境への移行は、サンドボックス サーバーのテストが完了した後に行います。
Google の予約サーバーのリクエストはすべて、予約サーバーの URL を基準にしています。
設定は
[予約サーバー]
ページで行います。たとえば、URL を「api.example.com/google」に設定している場合、
HealthCheck リクエストはすべて「api.example.com/google/v3/HealthCheck」に送信されます。
環境スイッチャーを使用して、サンドボックス環境と本番環境の両方に正しい予約サーバーのエンドポイントが構成されていることを確認してください。
セキュリティと認証
予約サーバーへの通信はすべて、基本認証を使用して HTTPS 経由で行われます。サーバーの設定では、 Qualys の SSL Server Test などの一般公開 されている SSL または TLS 検証ツールを使用することをおすすめします。
Google が予約サーバーに対して行うすべてのリクエストは、HTTPS 基本認証を使用して認証されます。予約サーバーの基本 認証情報、パスワード、ユーザー名は、 アクション センターの 予約サーバーの設定ページで入力できます。認証情報は 6 か月ごとに変更する必要があります。
予約サーバーを構築する
予約サーバーは、統合がシステムと通信して予約を作成または更新する方法を決定します。サンドボックスと 本番環境の予約サーバーへの接続を設定する方法については、 予約サーバーの認証情報を設定するをご覧ください。
予約サーバーが「Google で予約」からのリクエストに対して行うすべてのレスポンスには、正確なリアルタイムの在庫詳細情報が含まれている必要があります。以下の表には、各実装のメソッドと、サービス プロトコル形式へのリンクがまとめられています。
| メソッド | 定義 | レスポンス | HTTP リクエスト |
|---|---|---|---|
BatchAvailabilityLookup ページ読み込み |
ユーザーが販売者の [Reserve a Table] をクリックすると、
ペイロードには、最新のフィード アップロードに基づく多数のスロットが含まれており、「Google で予約」ではこれらが利用可能と見なされます。 |
レスポンスには、すべてのスロット リクエストとスロットの現在の 空き状況を含める必要があります。これにより、利用できないスロットが 表示されるのを防ぐことができます。 | POST /v3/BatchAvailabilityLookup/ |
BatchAvailabilityLookup スロットのクリック |
ユーザーに予約可能なスロットが表示され、ユーザーがスロットをクリックすると、スロットのクリック時に BatchAvailabilityLookup リクエストが呼び出されます。 |
レスポンスは、スロットの現在の実際の空き状況を表す必要があります。 スロットのクリック前に予約が完了した場合は、 利用できないことを示すレスポンスを返します。 | POST /v3/BatchAvailabilityLookup/ |
CreateBooking |
ユーザーが予約モーダルで選択した時間枠の予約を確定すると、CreateBooking リクエストが送信されます。 |
レスポンスは、予約の成功または失敗を表す必要があります。 予約が失敗した場合は、失敗の具体的な理由を返す必要があります。たとえば、スロットが
予約が成功すると、レスポンスには一意の
|
POST /v3/CreateBooking/ |
UpdateBooking |
「Google で予約」を通じて予約を行った後、ユーザーは予約を変更できます。ユーザーが予約を更新またはキャンセルすると、UpdateBooking リクエストが送信されます。 |
CreateBooking レスポンスと同様に、
UpdateBooking へのレスポンスは予約の成功を表すか、
失敗の具体的な理由を返す必要があります。 |
POST /v3/UpdateBooking/ |
HealthCheck |
アクション センターは、インフラストラクチャがアクティブで実行されていることを確認するために、予約サーバーを定期的に呼び出します。 | HTTP ステータス コードを使って、サーバーの配信ステータスを示します。 サーバーがアクティブで正常に動作している場合は、HTTP ステータス コード 200 を返します。 エラーを示す場合や、統合を一時的にオフラインにする場合は、 適切な 2xx 以外の HTTP ステータス コードを返します。 |
GET /v3/HealthCheck/ |
マイルストーンの条件
予約サーバーの準備完了のマイルストーンを完了するには、統合がサンドボックス環境と本番環境で次の条件を満たしている必要があります。
| メソッド | リクエストの必須数（サンドボックス） | リクエストの必須数（本番環境） | 必要な成功率 |
|---|---|---|---|
BatchAvailabilityLookup
ページ読み込み |
20 | 20 | 90% |
BatchAvailabilityLookup
スロットのクリック |
20 | 20 | 90% |
CreateBooking |
10 | 3 | 90% |
UpdateBooking |
10 | 3 | 90% |
サンドボックスの予約フロー
サンドボックスの予約フローを表示するには、アクション センターの 在庫ビューに移動します。在庫ビューの [RwG - E2E] 列には、一致するサンドボックス販売者で今後利用可能な サンドボックス予約フローへの [ライブ（サンドボックス内）] リンクが表示されます。
予約フローのアクションは次のとおりです。
[RwG - E2E] リンクをクリックすると、ページの読み込み時に
BatchAvailabilityLookupリクエストがトリガーされ、販売者の既知の空き状況が表示されます。予約時間枠をクリックすると、スロットのクリック時に
BatchAvailabilityLookupリクエストがトリガーされ、予約モーダルが表示されます。予約モーダルで予約を完了して、
CreateBookingリクエストを送信します。サンドボックス環境で予約を完了すると、予約の作成に使用したアカウントに予約の詳細が記載された確認メールが届きます。
UpdateBookingメソッドをトリガーするには、メールから予約を変更またはキャンセルします。
HealthCheck
サンドボックスと本番環境で HealthCheck メソッドを実装してください。このメソッドでは、予約サーバーの健全性ステータスを返します。これにより、Google は予約サーバーの配信状態を継続的にモニタリングできます。
リクエスト: なし
戻り値: なし
HTTP ステータス コードを使って、サーバーの配信ステータスを示します。
サーバーがアクティブで正常に動作している場合は、HTTP ステータス コード 200 を返します。 エラーを示す場合は、 HTTP ステータス コードの 1 つを返してください。