ステップ 4: 予約サーバーを導入する

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

  • 標準の実装。これにより、ユーザーに代わって Actions Center で予約を作成できます。

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

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

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

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

メソッド

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

標準の実装
標準のサービス定義 proto サービス定義ファイルをダウンロードします。
メソッド HTTP リクエスト
HealthCheck GET /v3/HealthCheck/
BatchAvailabilityLookup POST /v3/BatchAvailabilityLookup/
CreateBooking POST /v3/CreateBooking/
UpdateBooking POST /v3/UpdateBooking/
GetBookingStatus POST /v3/GetBookingStatus/
ListBookings POST /v3/ListBookings/

API リソース

Booking

標準の実装では次のリソースタイプが使用されます。

  • Slot: 広告枠。
  • Booking: 空き時間枠の予約。

フロー: 予約を作成

このセクションでは、標準の実装で予約を作成する方法について説明します。

図 1: 時間枠からの予約作成のワークフロー
図 1: 時間枠からの予約作成のワークフロー

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

セキュリティと認証

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

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

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

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

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

要件

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

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

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

標準の実装では、潜在的なビジネス ロジックのエラーは BookingFailure に記録され、HTTP レスポンスで返されます。リソースが作成または更新されると、ビジネス ロジックのエラーが発生することがあります。たとえば、メソッド CreateBooking や UpdatingBooking を処理する場合です。例は以下のとおりです（ただしこれらに限定されません）。

  • リクエストされた時間枠が使用不可になった場合は、SLOT_UNAVAILABLE が使用されます。
  • 指定されたクレジット カードの種類を承認できない場合は、PAYMENT_ERROR_CARD_TYPE_REJECTED が使用されます。

べき等性

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

  • CreateBooking
  • UpdateBooking

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

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

  • 成功した CreateBooking HTTP レスポンスには、作成された予約が含まれます。場合によっては、予約フローの一部として決済が処理されます。同じ CreateBookingRequest を 2 回受け取った場合（idempotency_token も同じ）は、同じ CreateBookingResponse を返す必要があります。2 回目の予約は作成されず、その場合、ユーザーは 1 回のみ請求されます。

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

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

前へ
ステップ 3: フィードをエクスポートする
次へ
ステップ 5: リアルタイム API 更新を実装する