0

サイトを追加、認証、および集約するための 2 行の API があるようです。担当者が開始したドキュメンテーション/SDK セットのバージョン、または SDK ガイドのどこから実装を開始したかによって、どこから開始するかが決まります。

パス #1 の開始時刻

  • すべての ContentServiceInfo の取得を可能にする ContentServiceTraversal (コンテナ タイプ (BANK など) ごと)
  • ItemManagementService は、これらのアイテムを追加するために使用されます
  • 更新は RefreshService を介して行われます (ほとんどの API には Site という単語が含まれていません)。

パス #2 の開始時刻

  • すべての SiteInfo の取得を可能にする SiteTranversalService (コンテナ タイプ フィルタの明らかなサポートなし)
  • SiteAccountManagementService は、これらのアイテムを追加するために使用されます
  • 更新は、Refreshservice (サイトという単語を含むすべての API) を通じて行われます。

前述の API には多くの機能の重複があることがわかります。特定の API が 1 つのブランチに存在し、他のブランチには存在しないことに気付きましたが、通常はマイナーな変更です (たとえば、フィルタリングできるもの)。

担当者が最初に提供してくれたドキュメントとサンプルがそこから始まったので、ContentServiceInfo から始めました。さらに、この API はより大きな粒度を提供することから始まりました (たとえば、銀行とプロセッサのサイトにしか関心がなかったので、コンテナの種類でフィルタリングできるようになりました (これは皆さんがサポートしているとは思いません))。

私の質問は次のとおりです。

  1. API の 2 つのブランチはまったく同じことを行いますか?
  2. 彼らはほとんど同じように振る舞いますか？
  3. それらはまったく同じにバックエンドしますか
    • システム
    • データ ストア
    • スクレーパー？
  4. API のある行は、他の行よりも早く廃止される予定ですか?
  5. 実際に新しい機能を追加したり、既存の機能を拡張したりするという点で、API の 1 つの行に将来性はありますか?
4

1 に答える 1

1

Yodlee API を介してサイト レベルの追加が導入され、ユーザーは同じエンド サイトで銀行、クレジット カード、ローン、報酬のアカウントを持っていても、ユーザーはこれらのコンテナーごとに資格情報を提供する必要があるという事実を克服しました。サイト レベルの追加 API は、1 セットの資格情報のみを使用して、これらすべてのコンテナーを追加しようとします。これが、コンテナ ベースの追加とサイト ベースの追加の唯一の違いです。

あなたの質問に答えるために：

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

集計機能を意味する場合は、はい。サイト レベルですべてのコンテナー (銀行、クレジットカード、ローン、報酬) を追加/更新し、コンテナー レベルで API 呼び出しごとに 1 つのコンテナーのみを追加/更新できるという事実を除いて、他のすべての動作は同じまま。 

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 に答える