CreateBooking Ready

如要完成「準備」CreateBooking里程碑工作，您必須成功建構並交付 CreateBooking 方法。使用者嘗試建立預訂時，系統會呼叫這個方法。如果成功建立預訂，回應會包含專屬的 booking_id，供日後要求或更新時參照預訂。

CreateBooking 工作需求

• 在 Sandbox 中提出 10 項 CreateBooking 要求，成功率達 90% 以上。
• 正式環境中 3 CreateBooking 要求，成功率達 90% 以上。

CreateBooking 基本概念

使用者發起預訂時，系統會將 CreateBooking 要求傳送至合作夥伴預訂伺服器。要求的回應會指出預訂成功或失敗。如果預訂失敗，回應中必須包含導致失敗的商業邏輯錯誤。舉例來說，時段已無法預約，或已由同一位使用者預訂。

使用者建立預訂時，Google 會將使用者的姓名、電話號碼和電子郵件地址傳送給您。詳情請參閱「帳戶比對和建立政策」。

注意：商業邏輯錯誤必須在 CreateBookingResponse.booking_failure 欄位中傳回，而非透過非 200 的 HTTP 回應代碼。

警告：因時段無法預訂而導致預訂失敗，視為 CreateBooking 錯誤。如果發生大量 CreateBooking 錯誤，整合功能可能會遭到停用。CreateBooking供應情形錯誤率偏高表示BatchAvailabilityLookup預約時段點擊回應無法準確反映即時庫存。

冪等

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

• CreateBooking
• UpdateBooking

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

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

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

  注意： 如果 CreateBooking 嘗試失敗且系統重新傳送同樣要求，您的後端必須重試 CreateBooking 要求。

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