Yodlee API：ContentServiceInfos与SiteInfos

Question

似乎有两行API用于添加，验证和聚合网站。根据您的代表启动的文档/ SDK集的版本，或者您开始​​实施的SDK指南中的位置决定了您的开始位置。

路径＃1从

开始

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

路径＃2从

开始

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

从最好的我可以告诉前面提到的API有很多功能重复。我注意到某个分支上存在某个API而不是另一个分支，但通常它们是微小的变化（例如，您可以过滤的东西）。

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

我的问题是：

1. API的两个分支是否完全相同？
2. 他们的行为大多相同吗？
3. 他们是否完全相同
   • 系统
   • 数据存储
   • 刮板？
4. 是否有一行API应该在未来更快地被弃用？
5. 在实际添加新功能或增强现有功能方面，一行API是否会有更多未来？

Answer 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都能满足不同的需求。如果您是一家完全依赖于Creditcard数据的公司，那么使用网站级别添加将是过度的，因为聚合需要更长的时间，并且使用基于容器的添加更有意义。还有向后兼容的因素，它排除了API的弃用。