Google Ads API is returning to beta status. Please read our blog post for more details.

AdWords API 翻译层的可行性

迁移时,您可能会想:为了节省开发时间和保留旧代码,尤其是考虑到常见的遗留概念,是否可以在 AdWords API 和 Google Ads API 之间创建 shim 或翻译层?

遗憾的是,创建翻译层无法对开发资源进行有效的利用,原因如下:

  • AdWords API 和 Google Ads API 之间存在巨大的语义差异,会让翻译层变得十分复杂。

  • AdWords API 已稳定运行近十年。我们希望 Google Ads API 的使用寿命也能达到如此之长,值得进行一次性迁移。

  • AdWords API 基于旧版 Google AdWords 界面,该界面已被弃用。Google Ads API 更类似于新版 Google Ads 界面。

  • 只要底层 Google Ads API 发生更改,就必须更新 shim。这会产生难以预测的额外维护费用,尤其是当这些更改违背了有关 AdWords API 功能的预先设想时。

  • 新功能的推出速度会更快。受旧版 AdWords API 的限制,shim 层要么必须创建自定义方式才可以显示新的功能,要么就不利用新的功能。如果您需要满足 RMF 规定,则可能会对合规性产生影响。

  • 即使在同一个进程中,也可以同时使用这两个 API,这可减少向新平台的增量迁移工作。

  • 由于使用 XML 编码,AdWords API 包含的数据类型信息有限。但 Google Ads API 属于增强型,所以,采用此前对于特定数据类型的设想,例如双精度浮点值,可能会破坏先前的代码。

语义差异

这两个 API 在以下几个方面的语义差异最大:

对象定义和层次结构
在为可预见的未来创建新的 API 时,我们借机为对象结构进行了一些改进,包括层次结构和属性。AdWords API 对象与 Google Ads API 对象之间不存在一对一的映射关系。例如,BudgetOrderService 就有显著的不同。
报告
AdWords API 提供的是单独的报告和管理功能。但在 Google Ads API 中,所有报告数据均以指标的形式返回,与查询中可能也包含管理信息的任何其他字段一样。这种统一性可降低众多应用中的代码复杂度。
AdWords API 报告会以 CSV 格式返回各种数据,其中复杂的对象会转换为字符串表示形式。CriteriaParameters 就是这样一个常见的示例,它需要经过解析才能提取有关每个条件的相关数据。Google Ads API 与之不同,它会返回完整的对象和报告指标。如果是在 AdWords API 方法中使用 shim,那么您必须选择最低标准,就会因此而错过 Google Ads API 的统一管理和报告功能所带来的显著优势。
查询语言
查询语言中,虽然语法之间的差异相对较小,但资源名称、字段名称和枚举之间存在明显的语义差异。某些 AdWords API 服务已拆分或重新组合成不同的 Google Ads API 服务。
精确的帐号管理
借助 login-customer-id,Google Ads API 可以更精确地控制经理帐号层次结构。对于使用经理帐号中的 OAuth 凭据的 Google Ads API 而言,其调用都必须包含此信息,而此信息可由客户端库轻松地进行处理。不使用这一新功能可能会出现结算和隐私问题。

特定服务

以下 AdWords API 服务已被大幅更改,或已被完全替换:

底层传输和编码

AdWords API 使用 SOAP / XML 作为传输协议。Google Ads API 客户端库则使用 gRPC 和编码效率高的协议缓冲区

在传输大量数据时,新机制的效率应该更高。根据调用程序针对网络重试、错误处理、HTTP 代理和其他网络依赖性做出的假设,shim 层中可能存在显著的行为差异。

总结

刚开始时,构建 shim 层表面上看起来可能很有吸引力,但与一次性迁移到 Google Ads API 相比,实际上成本可能会更高,导致的问题也可能更多。