このページは Cloud Translation API によって翻訳されました。

ステップ 3: 順番待ちの予約サーバーを導入する

Actions Center がコールバックを実行して予約の作成と更新を代行できるように、予約サーバーを構築する必要があります。

予約の順番待ちリストの実装。予約の順番待ちリストのパイロットプログラムに参加する場合に使用します。これにより、Actions Center はユーザーに代わって待ち時間の推定値を取得し、順番待ちリストのエントリを作成できます。
標準の実装。これにより、Actions Center はユーザーに代わって予約、予約、予約を作成できます。予約のエンドツーエンド統合用に予約サーバーを導入するには、予約サーバーを導入するをご覧ください。

サンドボックスと本番環境の予約サーバーへの接続を設定する方法については、パートナーポータルのドキュメントをご覧ください。

REST API インターフェースを実装する

REST に基づいて API インターフェースを実装します。これにより、Google のシステムが HTTP 経由で予約サーバーリクエストを送信できるようになります。

まず、Actions Center のサンドボックス環境に接続できる開発用またはサンドボックス用の予約サーバーを設定します。本番環境への移行は、サンドボックスサーバーのテストが完了した後に行います。

メソッド

予約サーバーのタイプごとに、異なる API メソッドのセットが必要です。必要に応じて、サービス定義を proto 形式でダウンロードして、API の実装を開始できます。次の表に、各実装のメソッドと、proto 形式のサービスへのリンクを示します。

順番待ちリストの実装
順番待ちリストのサービス定義 proto 形式のサービス定義ファイルをダウンロードします。

メソッド	HTTP リクエスト
HealthCheck	GET /v3/HealthCheck/
BatchGetWaitEstimates	POST /v3/BatchGetWaitEstimates/
CreateWaitlistEntry	POST /v3/CreateWaitlistEntry/
GetWaitlistEntry	POST /v3/GetWaitlistEntry/
DeleteWaitlistEntry	POST /v3/DeleteWaitlistEntry/

API リソース

ウェイティングリスト

順番待ちリストベースの予約の実装では、以下のリソースを使用します。

WaitEstimate: 特定の人数と販売者の待ち時間の推定値。
WaitlistEntry: 順番待ちリスト内のユーザーのエントリ。

フロー: 順番待ちリストのエントリを作成

このセクションでは、予約の順番待ちリストの統合で予約を作成する方法について説明します。

図 2: 順番待ちリストのエントリを作成するワークフロー — 図 2: 順番待ちリストのエントリ作成のワークフロー

ユーザーが順番待ちリストのエントリを作成すると、そのユーザーの氏名、電話番号、メールアドレスが販売者に送信されます。メールアドレスはユーザーの Google アカウントと同一であり、一意の識別子として扱われます。「Google で予約」では、販売者のシステム内のユーザーアカウントを検索できないため、この順番待ちリストは、「ログインせずに決済」として処理する必要があります。最終的な順番待ちリストのエントリが、販売者の順番待ちリストのシステム内のエントリと同じであることを確認します。

セキュリティと認証

販売者への予約サーバーへの通信はすべて HTTPS 経由で行われるため、サーバーの DNS 名と一致する有効な TLS 証明書が必要です。サーバーの設定では、Qualys の SSL Server Test などの無料の SSL/TLS 検証ツールを使用することをおすすめします。

Google が販売者の予約サーバーに対して行うすべてのリクエストは、HTTP 基本認証を使用して認証されます。販売者の予約サーバーの基本認証の認証情報（ユーザー名とパスワード）は、パートナーポータルの [予約サーバーの設定] ページで入力できます。パスワードは 6 か月ごとに変更する必要があります。

スケルトン実装のサンプル

最初に、以下のスケルトンのサンプルをご覧ください。Node.js と Java フレームワーク用に作成された予約サーバーのものです。

Node.js スケルトン js-maps-booking-rest-server-v3-skeleton
Java スケルトン java-maps-booking-rest-server-v3-skeleton

これらのサーバーでは、REST メソッドがスタブアウトされていますが、

要件

HTTP エラーとビジネスロジックのエラー

バックエンドで HTTP リクエストを処理する際は、2 種類のエラーが発生することがあります。

インフラストラクチャまたは不正なデータに関連するエラー
- これらのエラーは、標準の HTTP エラーコードを使用してクライアントに返します。HTTP ステータスコードの一覧をご覧ください。
ビジネスロジックに関連するエラー
- HTTP ステータスコードを 200 OK に設定して返します。ビジネスロジックの失敗はレスポンス本文で指定します。発生する可能性があるビジネスロジックのエラーのタイプは、サーバー実装のタイプによって異なります。

予約の順番待ちリストの統合では、ビジネスロジックのエラーは WaitlistBusinessLogicFailure に記録され、HTTP レスポンスで返されます。CreateWaitlistEntry メソッドを処理する場合など、リソースの作成時にビジネスロジックのエラーが発生することがあります。再利用されたコンテンツの例には以下のものが含まれますが、これらに限定されません。

リクエストされた順番待ちリストのエントリが、販売者の最大人数を超えた場合は、ABOVE_MAX_PARTY_SIZE が使用されます。
MERCHANT_CLOSED は、販売者がすでにビジネスを閉鎖しているため、順番待ちリストが開かれていない場合に使用されます。

べき等性

ネットワーク経由の通信は常に信頼できるわけではなく、Google のシステムは、レスポンスを受信でない場合に HTTP リクエストを再試行することがあります。そのため、状態を変化させるメソッドは、すべてべき等性を確保する必要があります。

CreateWaitlistEntry
DeleteWaitlistEntry

DeleteWaitlistEntry 以外のすべてのリクエストメッセージには、リクエストを一意に識別するため、べき等性のトークンが含まれます。これにより、1 つのリクエストを作成する目的で再試行された REST 呼び出しと、2 つの別々のリクエストを区別できます。DeleteWaitlistEntry は、順番待ちリストエントリの ID で一意に識別されるため、べき等性のトークンはリクエストに含まれません。

予約サーバーでのべき等性の処理方法の例は以下のとおりです。

成功した CreateWaitlistEntry HTTP レスポンスには、作成された順番待ちリストエントリの ID が含まれます。同じ CreateWaitlistEntryRequest を 2 回受け取った場合（idempotency_token も同じ）は、同じ CreateWaitlistEntryResponse を返す必要があります。2 つ目の順番待ちリストエントリは作成されず、エラーも返されません。

CreateWaitlistEntry の試行が失敗し、同じリクエストが再送信された場合は、バックエンドで再試行する必要があります。

べき等性の要件は、状態を変更するすべてのメソッドに適用されます。

ステップ 2: フィードをエクスポートする

ステップ 4: エンドツーエンドのテスト