0

似乎有两行 API 用于添加、验证和聚合站点。取决于您的代表开始使用的文档/SDK 版本，或者您开始​​实施的 SDK 指南中的哪个版本决定了您从哪里开始。

路径 #1 开始于

  • ContentServiceTraversal 允许检索所有 ContentServiceInfo（按容器类型（例如 BANK）
  • ItemManagementService 用于添加这些项目
  • 刷新是通过 RefreshService 完成的（大多数 API 不包含 Site 一词）

路径 #2 开始于

  • 允许检索所有 SiteInfo 的 SiteTranversalService（对容器类型过滤器没有明显的支持）
  • SiteAccountManagementService 用于添加这些项目
  • 刷新是通过 Refreshservice 完成的（所有 API 都包含单词 Site）。

据我所知，上述 API 有很多重复的功能。我注意到某些 API 存在于一个分支而不是另一个分支上，但通常它们是微小的变化（例如，您可以过滤的东西）。

我从 ContentServiceInfo 开始，因为我们的代表最初给我们的文档和示例是从那里开始的。此外，这个 API 开始提供更大的粒度（例如，简单地能够按容器类型进行过滤，因为我们几乎只对银行和处理器站点感兴趣（我不相信你们支持））。

我的问题是：

  1. API的两个分支做同样的事情吗？
  2. 他们的行为方式大多相同吗？
  3. 它们的后端是否完全相同
    • 系统
    • 数据存储
    • 刮刀？
  4. 是否应该比另一行更早地弃用 API 行？
  5. 就实际添加新功能或增强现有功能而言，一条 API 是否有更多未来？
4

1 回答 1

1

通过 Yodlee API 引入了站点级添加，以克服这样一个事实：尽管用户在同一终端站点拥有银行、信用卡、贷款、奖励账户，但用户必须为每个容器提供凭据。站点级添加 API 尝试仅使用一组凭据添加所有这些容器。这是基于容器的添加和基于站点的添加之间的唯一区别。

至于回答你的问题：

Do the two branches of API do the exact same thing?
Do they mostly behave the same way?

如果您指的是聚合功能，是的。除了站点级别添加/刷新所有容器（银行、信用卡、贷款、奖励）和容器级别每次 API 调用只能添加/刷新一个容器这一事实之外，所有其他行为将保持不变。 

Do they back-end to the exact same
    System
    Data store
    Scraper?

如果您指的是 Yodlee 数据收集组件，是的。

Is one line of API supposed to be deprecated sooner in the future than another?

不会。这两组 API 都满足不同的需求。如果您是一家仅依赖信用卡数据的公司，那么使用站点级添加将是多余的，因为聚合需要更长的时间，并且使用基于容器的添加更有意义。还有向后兼容性的因素，它排除了 API 的弃用。

于 2013-11-01T11:30:35.067 回答