您必須啟用預訂伺服器，讓 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：等候名單上的使用者項目。
流程：建立等候名單項目
本節說明如何為預訂等候名單整合建立預訂。
使用者建立等候名單項目時，Google 會將使用者的姓名、電話號碼和電子郵件地址傳送給您。這封電子郵件與使用者的 Google 帳戶相同，且系統會將其視為唯一識別碼。從您的角度來看，這份等候名單必須視為訪客結帳，因為「透過 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 回應中傳回這些錯誤。建立資源時可能會發生商業邏輯錯誤，例如處理 CreateWaitlistEntry 方法時。相關示例包括但不限於下列幾項：
- 如果要求的等候名單項目超過商家的預訂人數最高限制，系統就會使用
ABOVE_MAX_PARTY_SIZE。 - 由於商家已關閉，因而未開放等候名單時，系統會使用
MERCHANT_CLOSED。
冪等
網路通訊有時不一定可靠；如果未收到任何回應，Google 可能會重試 HTTP 要求。因此，所有會使狀態變動的方法都必須為冪等：
CreateWaitlistEntryDeleteWaitlistEntry
對於 DeleteWaitlistEntry 以外的所有要求訊息，系統會提供專屬的冪等代碼，以辨識該要求。這可讓您區分重試的 REST 呼叫，確定呼叫是要建立單一要求，還是兩個不同的要求。DeleteWaitlistEntry 會分別以專屬的等候名單項目 ID 來識別，因此這類要求中不包含冪等代碼。
以下是預訂伺服器處理冪等的一些範例：
成功的
CreateWaitlistEntryHTTP 回應會包含已建立的等候名單項目 ID。如果第二次收到相同的CreateWaitlistEntryRequest(具有相同的idempotency_token)，則必須傳回相同的CreateWaitlistEntryResponse。系統不會建立第二個等候名單項目，也不會傳回任何錯誤。請注意，如果發生
CreateWaitlistEntry嘗試失敗且系統重新傳送同樣要求的情況，您的後端應進行重試。
冪等要求適用於會使狀態變動的所有方法。