本文档提供了最佳实践指南。如需了解详情，请参阅效果提示。
何时使用 API
以程序化方式发送请求
无论您是希望自动执行工作流的各个部分，还是创建到 ERP（企业资源规划）系统的钩子机制，您都可以利用 Content API 在产品目录变更后尽快发送更新。
要收到即时反馈
在 Content API 中，您会即时收到每个请求的响应，而不是在处理数据 Feed 后通过电子邮件摘要来接收。大批量请求的延迟时间预计为 5 到 10 秒。
要经常更改您的商品数据
利用 Content API，您可以每天多次对快速变动的商品目录进行增量更新，而每次发送整个数据 Feed 并不可行。如果更新可以单独提供，请尽量单独发送，不要为了进行批量处理而积累多个更新。同样，如果可以进行批量更新，尽量批量发送，不要将更新分解到多个单独的请求。
要管理多个子账号
新创建的 Merchant Center 账号是单个账号，保存着各自的商品数据集。在大多数情况下，单个账号可以满足需求。但是随着账号数据的增加，您可能发现自己需要一个更复杂的商品管理系统。如果是这种情况，可以考虑使用多客户账号 (MCA)。您可以通过 Accounts 服务进行 MCA 账号的 API 级别管理，并允许以程序化方式添加和管理子账号。如需详细了解如何获取 MCA 账号，请点击此处。
如何使用该 API
不要像使用数据 Feed 一样使用 API
使用 products 资源时，请避免每天都更新整个商品 Feed。相反，只需专门更新实际更改了数据的商品。通过 products 资源发送整个数据 Feed 会占用 Google 和您的更多时间和资源。
请勿使用 API 定期检索您上传的商品信息
如果您负责维护特定 Merchant Center 账号中的商品信息，请避免定期通过 products.get 或 products.list 方法从 Content API 请求商品信息。对于上传信息的客户，这些方法有助于在设计使用 Content API 的解决方案时调试问题。但是，这些方法的设计用途并不是供客户定期检索商品信息。您应该有另一个商品信息来源（例如实体店商品数据库），并且 Merchant Center 中的商品应该反映此来源的内容。
请勿同时使用数据 Feed 和 Content API 来提交商品
如果您考虑改用 API 来提交商品，请确保不再使用数据 Feed 提交商品。如果您继续同时通过这两种方式提交商品，可能会出现意外结果。
有没有办法可以安全地同时使用 API 和数据 Feed？
您可以使用 API 的 Datafeed 服务来操纵您的数据 Feed。虽然此操作有助于更轻松地大规模管理数据 Feed，但是请记住，您不能同时使用 API 和 Feed 来插入或更新商品，因为可能会出现意外结果。
可以同时使用 Feed 和 API 的某些其他示例包括：
从 API 执行只读请求（get 或 list）：某些商家希望使用 API 提取商品的信息和状态更新。这种做法是可行的，因为商品信息只通过 Feed 更新。
使用 API 管理子账号（Accounts 服务）和/或账号级税费和运费设置（Accounttax 服务 和 Shippingsettings 服务）。Datafeeds 不能提供这些功能，因此不会与使用 API 管理这些功能发生冲突。
如何从使用数据 Feed 迁移到仅使用 API，或者如何从仅使用 API 迁移到使用数据 Feed？
如果您目前使用的是数据 Feed，并且想改为仅使用 API 更新商品，则需要使用 API 重新上传商品数据。当您使用 Products 服务更新给定商品时，该 API 会控制商品信息，从数据 Feed 中删除商品或删除数据 Feed 本身都不会再从您的 Merchant Center 账号中移除商品信息。如果要从数据 Feed 移除商品或移除数据 Feed 本身，请确保未进行数据 Feed 更新。否则数据 Feed 将再次控制商品，并且从数据 Feed 中移除商品将导致商品被移除。
如果您目前仅使用 API 获取商品信息，并且要将数据 Feed 用作商品信息的主要来源，则您只需将新的 Datafeed 添加到 Merchant Center 账号，它们就会控制所列商品。对于仅通过 API 上传的商品，如果您想要在这些商品过期之前将其移除，则必须通过 Merchant Center 或者 API 删除。
如何使用 Content API for Shopping 面向多个国家/地区投放商品？
若要面向多个国家/地区投放广告和非付费商品详情来宣传通过 Content API 提交的商品，请在 Merchant Center 中的 Content API 主要 Feed 上配置其他国家/地区，或通过 products 资源的 shipping 字段添加这些其他国家/地区。
以下示例展示了如何修改 Content API 主要 Feed 设置。
如需了解详情，请参阅面向多个国家/地区投放购物广告和非付费商品详情。
确保您的客户端库是最新版本
如果您使用 Google 客户端库与 Content API 进行交互，请务必使用所选编程语言的软件包管理器，并确保库版本是最新的。如需了解详情，请参阅示例和库中针对所选语言的开发者指南。
请务必使用目标平台属性来控制哪些商品会在不同的购物计划中展示
Content API 会自动采用 Content API Feed 在 Merchant Center 中配置的默认设置。您可以使用 includedDestinations 或 excludedDestinations 商品属性，在 Feed 中或通过 Content API 控制商品级别的活动参与情况。
如果您的 API Feed 已选择加入某项计划（例如“在 Google 上购买”[以前称为 Shopping Actions]），但您想排除某些商品，请使用 excludedDestinations 属性并将值指定为 Shopping Actions。如果没有错误，这将覆盖 Merchant Center 中的默认 Feed 设置，并且该特定商品将不会显示在“在 Google 上购买”（以前称为“购物行动”）中。反之，如果您的 Feed 尚未选择加入某个计划（例如购物广告），您可以使用 includedDestinations 属性并将 Shopping_ads 作为值来添加具体商品，该商品将在购物广告中展示。
如需详细了解 includedDestinations 和 excludedDestinations 商品属性，请访问帮助中心。
请务必在商品到期之前进行更新
如果在商品到期之前未进行更改，请在最后一次更新之后 30 天或者在指定的失效日期（以较早者为准）更新商品，以避免商品被停用。如果由于许多商品都未更改或者您无法跟踪商品的最后更新时间，因而需要更新许多商品，请不要同时更新所有商品，而是要将更新工作平均分配到几天中。
请勿删除 Content API Feed，否则您的商品可能会消失
首次通过 Content API 使用 channel:online 上传商品时，Merchant Center 中会显示一个名为 Content API 的新 Feed。首次通过 Content API 上传包含 channel:local 的商品时，Merchant Center 中会显示一个标题为 Content API 的新 Feed，其中包含一个标题为 Local Products 的子标题。请确保您不会意外删除在线或本地 Content API Feed。根据您删除的 Feed，系统会移除您通过 Content API 添加到 Merchant Center 中的线上商品或本地商品。
使用 custombatch 方法对同一服务的多个请求进行批处理
不要对同一服务发出许多依序或并行请求，而是要发出包含所有请求的单个 custombatch 请求。这样，向 API 端点发出请求时，只有 custombatch 调用会发生一次延迟，而不是各个请求都发生延迟，这对于发出依序请求而言非常重要。
不要在一个批处理中向单件商品发送多个更新
由于更新顺序的不确定性，这将导致结果不符合预期，并且可能造成冲突错误。
不要针对未更改的商品发送更新
确保您仅针对新商品、已更改的商品或已删除的商品发送请求，除非这些商品即将到期。
如果价格和/或库存状况快速变化，请使用补充 Feed
如果难以保持商品价格、库存状况或销售信息处于最新状态，请考虑使用 products 资源中的补充 Feed 发送仅针对这些属性的更新。由于补充 Feed 更新很少，因此与完整的商品更新相比，您可以在指定时间内发出更多的补充 Feed 更新，这有助于让商品的价格和库存状况与您的着陆页保持一致。
更新商品价格和库存状况的另一个途径是使用自动商品更新。此功能可用作 API 更新的补充，有助于避免 Merchant Center 中的信息与商品着陆页上的信息不匹配。但是，请记住，此功能旨在解决商品价格和库存状况准确性方面的小问题，因此自动商品更新不能代替通过 API 提供正确信息。
何时使用刷新令牌
刷新令牌会在授权请求的 HTTP 标头中返回。其中包含许多与身份验证相关的其他信息。但刷新令牌通常是开发者想要的，因为访问令牌的有效期仅为 60 分钟，不需要反复提示用户进行身份验证。