此页面由 Cloud Translation API 翻译。

概览

参与预订候位名单计划的合作伙伴必须先完成账号设置。不过，一般指南中的某些步骤并不适用于候位名单功能。本页面上的指南说明了哪些步骤适用于有兴趣在“通过 Google 预订”上使用候位名单功能的合作伙伴。我们建议您在查看集成步骤之前先看完本概览。

发布流程

图 1 所示为在 Google 易购中心上发布已启用候位名单功能的商家的流程。

从整体来看，您（合作伙伴）与 Google 之间的主要数据流如图 2 所示：

在实现预订候位名单功能时，请注意以下事项：

每个预订等候名单商家的服务都必须填充 waitlist_rules。
- 您必须使用同一服务进行候补和预订。换句话说，如果您的餐厅也允许预订，只需向服务中添加与等候名单相关的元数据即可进行预订。
在以下情况下，实现等候名单功能需要发送短信更新：
- 确认用户已成功加入候补名单。
- 用于通知用户其表格已准备就绪。
- 用于通知用户其候补名单条目已取消。
短信必须包含指向可供用户查看等候名单状态的网页的链接。
仅支持候位名单的商家无需向 Google 易购中心提供可用性 Feed。
您的预订服务器必须执行实现预订服务器中所列的所有特定于候位名单的步骤。同时支持预订和候位名单的合作伙伴可将新方法添加到其现有预订服务器。
Action Center 会为预订服务器中的候位名单方法运行一组测试用例。

此图表介绍了在响应 GetWaitlistEntry 调用时必须在 WaitlistEntry.waitlist_entry_state 中报告的状态。该图表还会指明何时记录和填充 WaitlistEntry.waitlist_entry_state_times.*_time_seconds 字段，以及何时向用户发送短信告知他们已进入新状态。

以下是预订候补名单集成中常见的极端情况及相关首选解决方案。

如果部分（但并非所有）人数不接受增加新的候位名单人数（因为基于这些人数无需等位），则在 BatchGetWaitEstimates 响应中返回所有人数的 WaitEstimates，并允许用户加入针对这些人数的候位名单，同时将不用等位作为首选项。返回 party_size 的 WaitLength（parties_ahead_count 为 0）和/或 estimated_seat_time_range（start_seconds 为 0 且 end_seconds 为 0），无需等待
如果一个或多个人数不接受增加新的候位名单人数（因为等待时间会过长），则首选在 BatchGetWaitEstimates 响应中忽略针对这些人数的 WaitEstimates。

这些方法为首选方法，因为即使商家的候位名单未完全开放，也会为用户提供选择。

如果预订服务器仅用于候位名单，请注意以下事项：

预订。仅支持候位名单的合作伙伴不会向“通过 Google 预订”提供空房情况 Feed。
预订。仅支持候位名单的合作伙伴不会在预订服务器中实现预订方法。而应由您实现预订服务器，并提供候位名单实现的相关说明。
预订：仅支持候位名单的合作伙伴无需向 Google 发送 API 调用请求。这意味着仅支持候位名单的合作伙伴无需设置云项目或提供开发者的电子邮件地址。您无需完成实时的 API 更新。不过，您仍需要向 Google 易购提供商家和服务 Feed。

如果您的商家要求能够手动接受或拒绝来自 Google 的添加新候位名单人数的请求，则需额外执行以下步骤：

对于需要手动确认的人数，请在 wait_estimate 中将 waitlist_confirmation_mode 设置为 WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS。必须在 BatchGetWaitEstimateResponse 和 GetWaitlistEntryResponse 中完成该设置。
已由用户请求但尚未被商家接受的候位名单条目应处于 PENDING_MERCHANT_CONFIRMATION 状态。

Google 会测试以下用例，以确保您的预订服务器实现中候位名单方法的功能正常运行。Google 还会测试和监控延迟情况。通过这些测试后才能发布。

系统会针对 BatchGetWaitEstimatesRequest 中的每个人数返回预计等待时间。
对于商家能够选择接受或拒绝添加新的候位名单人数的人数，请将 waitlist_confirmation_mode 设置为 WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS。

Google 希望对之前启用了候位名单功能，但决定停用的商家做出特定回应。