最佳实践

以下最佳做法适用于“通过 Google 预订”端到端集成，可以用于避免易用性和性能问题。数据质量低可能会导致商品目录被移除。

Feed

  • 如果服务未设置长度，请将可用性 Feed 中的 duration_sec 设置为以下某一项：
    • 以合理的方式执行服务所用的秒数。

    • 完成服务所需的平均秒数。

  • 确保商家 Feed 中的 Category 字段输入具体。例如，餐馆可以提交特定的类型，例如法语或日语。如需了解详情，请参阅地点类型，了解可能的类别值。

  • 在商家 Feed 的 Terms 字段中设置特定于商家的服务条款，以便在预订按钮下方显示以下备注：

    继续操作即表示您同意 <merchant> 的服务条款。
    在本例中，“服务条款”是一个链接，点击该链接即可查看“条款”文本字段中设置的文本。

  • 使用 gzip 压缩 Feed

预订服务器

若要优化 Maps Booking API 的集成，请执行以下操作：

  • 始终使用 UTC 格式的 UNIX 时间戳。
  • 在 CreateBooking API 中调用新的预订时，生成唯一的预订 ID。

实时更新

为确保在预订过程中提供最佳用户体验，请执行以下操作：

  • 对于标准实现，请使用 BookingNotifications API 更改预约的开始时间、持续时间和预订状态（例如取消或未显示）。
  • 如果您更改了“通过 Google 预订”功能提供的预订功能，请务必使用 BookingNotification API 从系统发送实时预订更新，以防数据通过“通过 Google 预订”功能过时。例如，您可以在自己的系统中通过“通过 Google 预订”取消、重新安排或更新预订。
  • 对于来自 UpdateBookingRequest 的每次预订更新，请确保 UpdateBookingResponse 值包含预订 ID，并且所有更新字段都必须反映新值。
  • 如果实现了库存 RTU
    • 每次更新 API 调用时，仅批量更新 100-1000 个槽。
    • 使用 *Restrict（例如 startTimeRestrict）字段缩小修改目标范围，减小载荷大小，并避免重新发送过多未更改的数据。
    • 如果您启动多个线程，请实现指数退避算法，以防发生节流错误。如果未正确实现指数退避，您可能会收到 RESOURCE_EXHAUSTED 配额错误。您可以重试指数退避算法来处理它们，但如果您发现运行 ReplaceServiceAvailability 时服务器通常达到配额，请将服务器配置为批量替换可用性。 此解决方案可防止配额错误，因为它减少了服务必须执行的 API 调用次数。
  • 将您的 API 调用响应时间限制在 1 秒以内。确保服务器可以至少处理 95% 的秒级查询 (QPS) 以及亚秒级延迟时间。