在你的後端設定預訂伺服器後，Actions Center 就能： 代表使用者與您建立預約 / 預訂 / 預訂。
根據 gRPC 實作 API 介面
請注意：所有新合作夥伴都應使用 REST API 介面，而非 gRPC 介面 API。
根據 gRPC 實作 API 介面。這樣 Google 就能傳送預訂要求。API 介面 是使用 gRPC 的 protobuf 式 IDL。
我們要求新合作夥伴實作一組建議的 API v2。合作夥伴可以 選取最適合自家基礎架構的網址和通訊埠。
本節將介紹一組建議的 API v2。凡是符合下列條件的合作夥伴， 尚未實作 API v0。適用於目前已導入 API 的合作夥伴 v0，如要瞭解詳情，請與 Actions Center 聯絡。
下載下方的 proto 格式服務定義，即可開始使用 API 實作。
API 資源
請熟悉下列資源類型 運作方式：
方法
請務必導入下列 API 方法， gRPC 伺服器：
這 5 種方法用來定義所需的 BookingService RPC 組合：
// Manages slot availability, leases and bookings for an inventory of
// appointments
service BookingService {
// Gets availability information for an appointment slot
rpc CheckAvailability(CheckAvailabilityRequest)
returns (CheckAvailabilityResponse) {}
// Creates a booking
rpc CreateBooking(CreateBookingRequest) returns (CreateBookingResponse) {}
// Updates an existing booking
rpc UpdateBooking(UpdateBookingRequest) returns (UpdateBookingResponse) {}
// Gets status for an existing booking
rpc GetBookingStatus(GetBookingStatusRequest)
returns (GetBookingStatusResponse) {}
// Lists all upcoming bookings for a user
rpc ListBookings(ListBookingsRequest) returns (ListBookingsResponse) {}
}
流程：建立預訂
建立預訂時，Google 會將使用者的姓名傳送給合作夥伴。 姓氏、電話號碼和電子郵件地址。視同 訪客可在合作夥伴的觀點上結帳，因為 Actions Center 並沒有 可在合作夥伴的系統中查詢使用者帳戶。最終預訂 對合作夥伴的商家顯示的資訊應與預訂相同 為合作夥伴的預訂系統提供不同的回應
Java 中的架構實作
首先，我們在 Java 中提供一個可編譯的基本架構 gRPC 伺服器 且已安裝應用程式查看方式 範例 >gRPC 參考實作 專區。這個伺服器已虛設常式以支援 gRPC 方法， 包括驗證和健康服務
需求條件
gRPC 錯誤和商業邏輯錯誤
當合作夥伴後端處理 gRPC 要求時，可能會發生兩種類型的錯誤： 不正確的資料導致的未預期錯誤；以及商業邏輯錯誤 表示無法建立或更新預訂 (請參閱「預訂」一節 失敗)； 例如要求的時段無法使用時。
如果發生未預期的錯誤，您應使用以下程式碼傳回用戶端： 標準 gRPC 錯誤代碼相關例子包括但不限於：
- INVALID_src 用於 RPC，例如 CheckAvailability 和 CreateLease 如果提供的版位含有無效的資訊，則應傳回該值。
- NOT_FOUND 用於建立遠端程序呼叫 (例如 CreateBooking 和 ListBookings)，且應該 如果合作夥伴無法取得提供的 ID，則會傳回 。
請參閱每種方法的標準 gRPC 錯誤代碼的參考資訊，或參閱完整 狀態碼清單。
相反地，請透過「預訂」分頁擷取商業邏輯錯誤 失敗，以及 。建立時可能會發生商業邏輯錯誤 或更新資源，例如處理遠端程序呼叫 (RPC) CreateBooking，及 正在更新預訂。相關例子包括但不限於：
- 如果要求的運算單元已無法使用，系統會使用 SLOT_UNAVAILABLE。
- 如果提供的信用卡類型為 PAYMENT_ERROR_CARD_TYPE_REJECTED 不接受。
冪等
透過網路通訊有時不穩定，Google Reserve 可能會 如未收到回應，則重試遠端程序呼叫 (RPC)。因此，所有會變更的 RPC 狀態 (CreateBooking、UpdateBooking) 必須為冪等要求訊息： 這些遠端程序呼叫 (RPC) 包含冪等符記，可明確識別要求，並允許 以利合作夥伴區分重試的遠端程序呼叫 (RPC) 以建立 一筆預訂) 和兩個獨立的預訂。
相關例子包括但不限於：
- 成功
CreateBooking 遠端程序呼叫
回應中會包含已建立的預訂。在某些情況下，
隨著預訂流程中處理如果 CreateBookingRequest 完全相同
第二次收到 (包括
idempotency_token)，則同樣 必須傳回 CreateBookingResponse。系統不會建立第二筆預訂，且 只需向使用者收取一次費用 (如適用)。 請注意，如果 CreateBooking 嘗試失敗，合作夥伴後端應重試 就會導致相同錯誤
冪等規定適用於所有包含冪等符記的方法。
gRPC 伺服器安全性和驗證
從 Actions Center 到後端的呼叫必須使用 SSL/TLS 來保護連線的安全 和以憑證為基礎的雙向用戶端/伺服器驗證。這需要用到 使用有效的伺服器憑證進行 gRPC 實作，並接受 有效的用戶端憑證。
伺服器憑證：合作夥伴伺服器必須配備有效的 與伺服器網域名稱相關聯的伺服器憑證 (請參閱 接受的根 CA 清單)。 GRPC 伺服器實作預期會提供的憑證鏈結，達到最高 而非根憑證最簡單的方法是將 合作夥伴的網站代管商以 PEM 格式提供給您的中繼憑證， 伺服器憑證 (也是 PEM 格式)。
伺服器憑證會在連線時驗證並自行簽署 系統不接受憑證。實際憑證內容不會經過檢查 因為憑證仍然有效你可以檢查憑證的有效性 執行下列指令：
echo "" | openssl s_client -connect YOUR_URL:YOUR_PORT -showcerts -CApath /etc/ssl/certs
用戶端憑證：為了向合作夥伴驗證我們 (即 Google)， 我們提供由 Google 網際網路授權 G2 (CA) 核發的用戶端憑證 憑證) 屬性：
| 欄位 | 值 |
|---|---|
CN |
mapsbooking.businesslink-3.net |
SAN |
DNS:mapsbooking.businesslink-3.net |
如果沒有這個用戶端憑證，連線嘗試應會遭到 合作夥伴伺服器
伺服器必須使用一組信任的用戶端來驗證用戶端憑證 根憑證。您可以選擇從 例如 Mozilla 或安裝 Google 網際網路目前建議的根層級組 授權單位 G2。兩者皆有 否則您可能得不時手動更新根憑證。
實作 gRPC 健康狀態檢查通訊協定
實作 GRPC 健康狀態檢查
Protocol (通訊協定)。
透過這項通訊協定，Google 可以監控 gRPC 的後端狀態
。服務
規格
隸屬於 GRPC 分佈的一環按照 GRPC 命名慣例
是透過健康狀態檢查呼叫的服務
ext.maps.booking.partner.v2.BookingService 適用於 API v2
ext.maps.booking.partner.v0.BookingService 代表 API v0。健康狀態檢查
以與其他端點相同的網址和 PORT 執行。
其他版本
如需其他 API 版本的說明文件，請參閱下列頁面： * API 第 3 版 * API 第 0 版