您必須啟用預訂伺服器，讓 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 資源
預訂
下列資源類型可用於標準導入：
流程：建立預訂
本節說明如何為標準導入建立預訂。
使用者建立預訂時，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 狀態碼設為
200OK，並在回應主體中指定商業邏輯失敗。不同類型的伺服器導入方式可能會出現不同類型的商業邏輯錯誤。
- 將傳回的 HTTP 狀態碼設為
對於標準導入作業，系統會從預訂失敗中擷取可能的商業邏輯錯誤，並在 HTTP 回應中傳回這些錯誤。建立或更新資源時可能會發生商業邏輯錯誤，例如處理 CreateBooking 或 UpdatingBooking 方法時。相關例子包括但不限於：
- 如果要求的時段已無法提供，系統會使用
SLOT_UNAVAILABLE。 - 如果系統不接受提供的信用卡類型，系統會使用
PAYMENT_ERROR_CARD_TYPE_REJECTED。
冪等
網路通訊有時不一定可靠；如果未收到任何回應，Google 可能會重試 HTTP 要求。因此，所有會使狀態變動的方法都必須為冪等：
CreateBookingUpdateBooking
對於 UpdateBooking 以外的所有要求訊息，系統會提供專屬的冪等代碼，以辨識該要求。這可讓您區分重試的 REST 呼叫，確定呼叫是要建立單一要求，還是兩個不同的要求。UpdateBooking 會分別以專屬的預訂項目 ID 來識別，因此這類要求中不包含冪等代碼。
以下是預訂伺服器處理冪等的一些範例：
成功的
CreateBookingHTTP 回應會包含已建立的預訂。在某些情況下，付款作業會在預訂流程中一併處理。如果第二次收到完全相同的CreateBookingRequest(具有相同的idempotency_token)，則必須傳回相同的CreateBookingResponse。系統不會建立第二筆預訂，且只會向使用者收取一次費用 (如適用)。請注意，如果發生
CreateBooking嘗試失敗且系統重新傳送同樣要求的情況，您的後端應進行重試。
冪等要求適用於會使狀態變動的所有方法。