最佳实践
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
以下最佳实践适用于与 Google 助理中心预订等候名单的集成,可用于避免易用性和性能问题。
数据质量较低可能会导致商品目录被移除。
Feed
预订服务器
如需优化 Google 地图预订 API 集成,请执行以下操作:
- 始终使用世界协调时间 (UTC) 格式的 UNIX 时间戳。
- 在调用
CreateBooking
API 中的新预订时,生成唯一的预订 ID。
实时更新
为确保在预订过程中提供最佳用户体验,请执行以下操作:
- 对于标准实现,请使用 BookingNotifications API 更改预约的开始时间、时长和预订状态(例如取消或未到)。
- 当您在 Google 助理中心进行的预订发生任何更改时,请务必使用 BookingNotification API 实时发送系统中的实时预订更新,以免 Google 助理中心端的数据过时。例如,您可以在 Action Center 中取消、重新安排或更新系统中的预约。
- 对于
UpdateBookingRequest
中的每项预订更新,请确保 UpdateBookingResponse
值包含预订 ID,并且所有已更新字段都必须反映新值。
-
如果实现了目录 RTU
- 每次 API 调用只能批量更新 100-1000 个空档的可用性。
-
使用
*Restrict
(例如 startTimeRestrict
)字段来缩小修改目标范围、减小载荷大小,并避免重新发送过多未更改的数据。
-
如果您拆分为多个线程,请实现指数退避算法,以防止节流错误。如果您未正确实现指数退避算法,可能会收到
RESOURCE_EXHAUSTED
配额错误。
您可以重试指数退避算法来处理这些错误,但如果您发现服务器在运行 ReplaceServiceAvailability
时经常达到配额,请将服务器配置为批量替换可用性。
此解决方案可防止配额错误,因为它会减少服务器必须进行的 API 调用次数。
- 将 API 调用响应时间限制设置为不超过 1 秒。确保您的服务器能够处理 5 个每秒查询次数 (QPS),且至少在 95% 的情况下处于次秒级延迟。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-26。
[null,null,["最后更新时间 (UTC):2025-07-26。"],[[["\u003cp\u003eMaintain high data quality in feeds to prevent inventory takedown and ensure accurate service representation.\u003c/p\u003e\n"],["\u003cp\u003eUtilize the \u003ccode\u003eduration_sec\u003c/code\u003e field in Availability feeds to specify service lengths, and use specific categories for better service classification.\u003c/p\u003e\n"],["\u003cp\u003eInclude merchant-specific terms of service in the Merchant feed for user transparency and agreement.\u003c/p\u003e\n"],["\u003cp\u003eImplement real-time booking updates using the BookingNotifications API to ensure data consistency and a seamless user experience.\u003c/p\u003e\n"],["\u003cp\u003eOptimize Booking Server and Inventory RTU API calls to enhance performance and minimize errors, such as using batch updates and implementing exponential backoff.\u003c/p\u003e\n"]]],["For Feeds, set service durations, use specific categories, include merchant terms of service, and compress feeds. The Booking Server should use UNIX timestamps and generate unique booking IDs. Real-time updates via the BookingNotifications API are essential for booking changes, with updates reflecting new values. Implement Inventory RTU using batch updates, `*Restrict` fields, and exponential backoff to avoid quota errors and set response times under one second.\n"],null,["# Best practices\n\nThe following best practices apply to the Actions Center Reservations Waitlists\nintegration and can be leveraged to avoid usability and performance issues.\nLow data quality might lead to inventory takedown.\n\nFeeds\n-----\n\n- If a service doesn't have a set length, set `duration_sec` in the Availability feed to one of the following:\n - The number of seconds it takes to perform the service in a reasonable manner.\n - The average number of seconds required to complete the service.\n\n | **Note:** If a length of `0` is submitted in the feed, our system counts that availability slot as invalid and doesn't show it on the Actions Center.\n- Make the `Category` field input in the merchant's feed is specific. For example, a restaurant might submit a specific type, such as French or Japanese. For details, see [Place types](/maps/documentation/places/web-service/supported_types) for potential category values.\n- Set merchant-specific terms of service in the `Terms` field\n of the Merchant feed so that the following note appears below the\n **Book** button:\n\n \u003cbr /\u003e\n\n \u003e By continuing, you agree to \u003cvar translate=\"no\"\u003e<merchant>\u003c/var\u003e's Terms of Service.\n In this case, \"Terms of Service\" is a link that, when clicked, displays the text set in the *terms* text field.\n\n \u003cbr /\u003e\n\n- [Compress your feeds using `gzip`](/actions-center/verticals/reservations/waitlists/reference/tutorials/compression)\n\nBooking Server\n--------------\n\nTo optimize your integration of the Maps Booking API, do the following:\n\n- Always use UNIX timestamps in UTC format.\n- Generate a unique booking ID when a new booking in the [`CreateBooking`](/actions-center/verticals/reservations/waitlists/reference/booking-server-api-rest/e2e-methods/createbooking-method) API is called.\n\nReal-time updates\n-----------------\n\nTo ensure the best user experience during the booking process, do the\nfollowing:\n\n- For a standard implementation, use the BookingNotifications API to change the start time, duration, and booking state, such as cancellation or no-show, of an appointment.\n- Upon any change on the Actions Center booking from your side, always send real-time booking updates from the system with the BookingNotification API in real-time so that the data doesn't become stale on the Actions Center side. For example, you can cancel, reschedule, or update a booking from your system in the Actions Center.\n- For every booking update from `UpdateBookingRequest`, make sure that the `UpdateBookingResponse` value contains the booking ID and that **all** updated fields must reflect the new value.\n- If [Inventory RTU](/actions-center/verticals/reservations/waitlists/integration-steps/real-time-api-updates) are implemented\n - Only update availability in batches of 100-1000 slots per API call.\n - Use `*Restrict` (such as `startTimeRestrict`) fields to narrow the edit target, reduce payload size and avoid re-sending too much unchanged data.\n - If you spin off several threads, implement an [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff) to prevent throttle errors. If you don't implement an exponential backoff correctly, you might get a `RESOURCE_EXHAUSTED` [quota error](/actions-center/verticals/reservations/waitlists/integration-steps/real-time-api-updates#api-quotas). You can retry the exponential backoff to handle them, but, if you find that your server often reaches quotas when you run `ReplaceServiceAvailability`, configure your server to [batch replace for availability](/maps-booking/reference/maps-booking-api/rest/v1alpha/inventory.partners.availability/replace). This solution prevents quota errors because it reduces the number of API calls your serve has to make.\n- Set your API call response time limits to less than one second. Ensure that your server can handle five queries per second (QPS) with sub-second latency at least 95% of the time."]]