導入預訂伺服器

您必須啟用預訂伺服器，讓 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 資源

預訂

下列資源類型可用於標準導入：

• Slot：廣告空間時段。
• 預訂：預約特定庫存清單時段。

流程：建立預訂

本節說明如何為標準導入建立預訂。

圖 1：從時段建立預訂的工作流程

使用者建立預訂時，Google 會將使用者的姓名、電話號碼和電子郵件地址傳送給您。從您的角度來看，這筆預訂必須視為訪客結帳，因為「行動中心」無法在您的系統中查詢使用者帳戶。請確認最終預訂資訊與您預訂系統中的商家預訂資訊一致。根據預設，針對不必先行付款的預訂形式，我們會支援訪客結帳及備用電子郵件功能。

安全性和驗證

所有與預訂伺服器的通訊都是透過 HTTPS 進行，因此您的伺服器必須具備與其 DNS 名稱相符的有效傳輸層安全標準 (TLS) 憑證。為協助您設定伺服器，建議您使用公開的 SSL/TLS 驗證工具，例如 Qualys 的安全資料傳輸層 (SSL) 伺服器測試。

Google 對您的預訂伺服器發出的所有要求都將使用 HTTP 基本驗證進行驗證。您可以在合作夥伴入口網站的「預訂伺服器設定」頁面中，輸入預訂伺服器的基本驗證憑證 (使用者名稱和密碼)。密碼必須每六個月輪替更換一次。

注意：您必須使用環境切換器，分別為沙箱和正式版設定使用者名稱和密碼。

範例基本架構導入

首先，請查看下列針對 Node.js 和 Java 架構撰寫的預訂伺服器基本架構範例：

• Node.js 基本架構 js-maps-booking-rest-server-v3-skeleton
• Java 基本架構 java-maps-booking-rest-server-v3-skeleton

這些伺服器已利用虛設常式模擬 REST 方法；

需求條件

HTTP 錯誤和商業邏輯錯誤

在後端處理 HTTP 要求時，可能會發生兩種錯誤類型。

• 基礎架構相關錯誤或資料錯誤
  • 將這些錯誤傳回給用戶端，並附上標準 HTTP 錯誤代碼。請參閱 完整的 HTTP 狀態碼清單。
• 與商業邏輯相關的錯誤
  • 將傳回的 HTTP 狀態碼設為 200 OK，並在回應主體中指定商業邏輯失敗。不同類型的伺服器導入方式可能會出現不同類型的商業邏輯錯誤。

對於標準導入作業，系統會從預訂失敗中擷取可能的商業邏輯錯誤，並在 HTTP 回應中傳回這些錯誤。建立或更新資源時可能會發生商業邏輯錯誤，例如處理 CreateBooking 或 UpdatingBooking 方法時。相關例子包括但不限於：

• 如果要求的時段已無法提供，系統會使用 SLOT_UNAVAILABLE。
• 如果系統不接受提供的信用卡類型，系統會使用 PAYMENT_ERROR_CARD_TYPE_REJECTED。

冪等

網路通訊有時不一定可靠；如果未收到任何回應，Google 可能會重試 HTTP 要求。因此，所有會使狀態變動的方法都必須為冪等：

• CreateBooking
• UpdateBooking

對於 UpdateBooking 以外的所有要求訊息，系統會提供專屬的冪等代碼，以辨識該要求。這可讓您區分重試的 REST 呼叫，確定呼叫是要建立單一要求，還是兩個不同的要求。UpdateBooking 會分別以專屬的預訂項目 ID 來識別，因此這類要求中不包含冪等代碼。

以下是預訂伺服器處理冪等的一些範例：

• 成功的 CreateBooking HTTP 回應會包含已建立的預訂。在某些情況下，付款作業會在預訂流程中一併處理。如果第二次收到完全相同的 CreateBookingRequest (具有相同的 idempotency_token)，則必須傳回相同的 CreateBookingResponse。系統不會建立第二筆預訂，且只會向使用者收取一次費用 (如適用)。

  請注意，如果發生 CreateBooking 嘗試失敗且系統重新傳送同樣要求的情況，您的後端應進行重試。

冪等要求適用於會使狀態變動的所有方法。