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

予約サーバーを実装する

「Google で予約」で、予約の作成と更新をコールバックで行えるように、予約サーバーを立ち上げる必要があります。

標準実装。これにより、「Google で予約」でユーザーに代わって予約を作成できます。

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

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

REST ベースの API インターフェースを実装し、Google が HTTP 経由で予約サーバーリクエストを送信できるようにします。

まず、「Google で予約」のサンドボックス環境に接続できる開発またはサンドボックス予約サーバーをセットアップします。本番環境への移行は、サンドボックスサーバーのテスト完了後に行ってください。

Methods

予約サーバーの種類ごとに、それぞれ異なる 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

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

スロット: 広告枠スロットです。
予約: 在庫枠の予約。

フロー: 予約を作成

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

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

セキュリティと認証

予約サーバーへの通信はすべて HTTPS を介して行われるため、DNS 名と一致する有効な TLS 証明書がサーバーに存在することが重要です。サーバーの設定を支援するため、一般公開されている SSL/TLS 検証ツール（Qualys の SSL サーバーテストなど）を使用することをおすすめします。

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 ステータスコードの全リストをご覧ください。
ビジネスロジックに関連するエラー
- 200 OK に設定された HTTP ステータスコードを返し、レスポンス本文でビジネスロジックの失敗を指定します。発生する可能性のあるビジネスロジックのエラーの種類は、サーバーの実装の種類によって異なります。

標準実装では、考え得るビジネスロジックのエラーは予約の失敗にキャプチャされ、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 の試行が失敗し、同じリクエストが再送信された場合は、この場合はバックエンドで再試行する必要があります。

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