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