第 3 步：实现等候名单预订服务器

您需要设置预订服务器，以允许 Action Center 进行回调，代表您创建和更新预订。

• 预订等候名单实现。如果您参与的是预订候补名单试行计划，便可使用该方式。这样一来，Actions Center 便可代表用户检索预计等待时间并创建候位名单条目。
• 标准实现。这样一来，Action Center 便可代表用户与您创建预约、预订和预留。如需为预订端到端集成实现预订服务器，请参阅实现预订服务器。

请参阅合作伙伴门户文档，了解如何配置与您的沙盒环境和生产环境中预订服务器的连接。

实现 REST API 接口

实现基于 REST 的 API 接口。Google 可借助该实现通过 HTTP 发送预订服务器请求。

首先，请设置一个可连接到 Action 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：用户在候位名单中的条目。

流程：创建候位名单条目

本部分将介绍如何为预订候补名单集成创建预订。

图 2：创建候位名单条目的工作流程

用户创建候位名单条目后，Google 会向您发送用户的名字、姓氏、电话号码和电子邮件地址。该电子邮件地址与用户的 Google 账号相同，且被视为唯一标识符。从您的角度来看，需要将该候位名单视为游客结账，因为“通过 Google 预订”无法在您的系统中查找用户的账号。请确保最终的候位名单条目与您的候位名单系统中显示的商家的条目相同。

安全和身份验证

与您的预订服务器之间的所有通信均通过 HTTPS 进行，因此您的服务器必须具有与其 DNS 名称匹配的有效 TLS 证书。建议您在设置服务器时使用免费的 SSL/TLS 验证工具，例如 Qualys 的 SSL 服务器测试。

Google 向您的预订服务器发出的所有请求都将使用 HTTP 基本身份验证进行身份验证。您可在合作伙伴门户的“预订服务器配置”页面输入预订服务器的基本身份验证凭据（用户名和密码）。必须每 6 个月更改一次密码。

注意：您必须使用环境切换器分别为沙盒环境和生产环境设置用户名和密码。

框架实现示例

要开始使用，请查看以下针对 Node.js 和 Java 框架编写的预订服务器的框架示例：

• Node.js 框架 js-maps-booking-rest-server-v3-skeleton
• Java 框架 java-maps-booking-rest-server-v3-skeleton

这些服务器已弃用 REST 方法。

注意：对于预订候补名单集成，请将 REST 方法更改为所需的预订候补名单方法。

要求

HTTP 错误和业务逻辑错误

您的后端在处理 HTTP 请求时可能会遇到两种类型的错误。

• 与基础架构相关的错误或数据不正确
  • 通过标准的 HTTP 错误代码将这些错误返回给客户端。 请参阅完整的 HTTP 状态代码列表。
• 与业务逻辑相关的错误
  • 将 HTTP 状态代码设置为 200 OK，并在响应正文中指定业务逻辑失败。对于不同类型的服务器实现，您可能会遇到的业务逻辑错误类型会有所不同。

对于预订候位名单集成，系统会在候位名单业务逻辑失败中捕获业务逻辑错误，并在 HTTP 响应中返回。创建资源时可能会遇到业务逻辑错误，例如当您处理 CreateWaitlistEntry 方法时。这样的示例包括但不限于：

• 如果请求的候位名单条目超过了商家设定的人数上限，请使用 ABOVE_MAX_PARTY_SIZE。
• 如果候位名单因商家已停止营业而未开放，请使用 MERCHANT_CLOSED。

幂等性

通过网络进行的通信并非始终可靠，如果 Google 未收到任何响应，可能会重试 HTTP 请求。因此，更改状态的所有方法都必须具有幂等性：

• CreateWaitlistEntry
• DeleteWaitlistEntry

对于除 DeleteWaitlistEntry 之外的每个请求消息，均包含幂等性令牌以标识身份唯一的请求。这使您能够区分重新提交的 REST 调用（旨在创建单个请求）和两个单独的请求。DeleteWaitlistEntry 分别由其候位名单条目 ID 进行唯一标识，因此这些请求中不包含幂等性令牌。

以下是一些有关预订服务器如何处理幂等性的示例：

• 成功的 CreateWaitlistEntry HTTP 响应包含已创建的候位名单条目 ID。如果再次收到相同的 CreateWaitlistEntryRequest（具有同一 idempotency_token），则必须返回相同的 CreateWaitlistEntryResponse。系统不会再次创建候位名单条目，也不会返回错误。

  请注意，如果 CreateWaitlistEntry 尝试失败，且重新发送了同一请求，在这种情况下，您的后端应进行重试。

幂等性要求适用于更改状态的所有方法。