留意点
MT LINK APIに対する開発される際に留意すべき項目
URLクエリパラメータに機密情報を送信しないでください
LINK APIへのリクエストでは、アクセストークン、リフレッシュトークン、クライアントシークレットなどの機密情報をURLクエリパラメータで送信しないでください。URLはサーバーログに記録されることが多く、これはURLパラメータとして送信された機密情報が第三者に漏れる可能性があることを意味します。
その代わりに、OAuth 2.0標準ドキュメントRFC 6749セクション2.3.1およびRFC 6750セクション2.3で定義されているように、リクエストボディに機密性の高い値を送信してください。
認証
code
を URL パラメータで送信することは安全ですか?認可要求の開始経由でLINK APIの認可フローを開始する場合、レスポンスはURLパラメータに
code
を指定してサーバにリダイレクトされます。これはcode
だけではアクセストークンを取得できないので安全です。これはclient_secret
(バックエンドサーバからリクエストする場合) または PKCEcode_verifier
(ウェブアプリケーションからリクエストする場合) を必要とします。
削除されたオブジェクトについて
Moneytreeの利用者はいつでも登録している情報を削除することができます(ゲストユーザーは、登録した金融サービスを削除することができます、また金融機関によっては、Open APIで金融機関が提供している設定機能などから、連携する科目を選択・解除することができる場合もあります。)。したがって、ある時点でAPIで取得できたデータであっても、それ以降にゲストが削除した場合は同じデータが取得できない可能性があります。
MoneytreeはIDを含め、削除されたオブジェクトを保存しません。こうしたデータを考慮したシステムを実装する必要があります。
例えば、個人口座APIをリクエストしても、以前存在したアカウントオブジェクト(Account
)がレスポンスの配列に存在しない場合があります。
こうしたオブジェクトは、同様に実装するシステムにおいて削除する、または、ゲストの画面には表示しないなど、適切な実装をおこなってください。
なお、取引明細データ(各/transaction.json
API)、および残高データ(各/balances.json
API)などの各レコードについては、Moneytreeが自動的に取得するデータであり、原則一度記録されたレコードは削除されることはございませんが、稀に正しくないデータなどが誤って取り込まれた場合などは削除されることがあります。
同時アクセス数の制限について
同じ送信元から1分以内に膨大なAPIアクセスが発生した場合、HTTP Statusコードで、429が返されます。
しかし、想定せず429を受け取る場合は、Moneytreeにお問い合わせください。
なお、特定のAPIによっては、大量のアクセスがない場合でも429が返されることがあります。
APIの並行処理について
APIのコールは、同時に複数のリクエストを並行してリクエストすることを推奨します。例えば、あるゲストの口座に4件の取引明細(Transaction)があり、これら4件をのデータを取得する場合です。
次1件ずつコールする場合、以下の流れになります:
GET /link/v1/accounts.json
==> [Account ID 1, Account ID 2, Account ID 3, Account ID 4]
GET /link/v1/accounts/1/transactions.json
==> [500 Transactions]
GET /link/v1/accounts/1/transactions.json?page=2
==> [100 Transactions]
GET /link/v1/accounts/2/transactions.json
==> [100 Transactions]
GET /link/v1/accounts/3/transactions.json
==> [0 Transactions]
GET /link/v1/accounts/4/transactions.json
==> [10 Transactions]
各レスポンスに、ネットワークのレイテンシーを含めて100ミリ秒かかった場合、この方法では、処理が完了するまでに600ミリ秒かかることになります。これはゲストにとって、長く感じてしまう可能性があります。
MoneytreeのAPIは、同一のゲストから複数のアクセスに対応しているため、以下のような実装がより効率的です。
GET /link/v1/accounts.json
==> [Account ID 1, Account ID 2, Account ID 3, Account ID 4]
# 4つのリクエストを同時にスタートさせる
GET /link/v1/accounts/1/transactions.json
GET /link/v1/accounts/2/transactions.json
GET /link/v1/accounts/3/transactions.json
GET /link/v1/accounts/4/transactions.json
# 6行目のリクエストが返されたらこちらがリクエストされる
GET /link/v1/accounts/1/transactions.json?page=2
それぞれのリクエストのレスポンスが同程度だとした場合、この方法では300ミリ秒程度であり、半分の時間で処理が完了することが期待されます。
こうした並列的な処理は、順次リクエストする場合に比べ、やや複雑な実装になるかもしれませんが、ゲストの増大に対してよりスケーラブルで、よりメンテナンスが容易な構成になることが期待されます。
start
、end
とsince
の引数について
start
、end
とsince
の引数について各Transactions APIエンドポイント (reference)には、start
、end
、そしてsince
のパラメータがあります。
start
および、end
はいずれもdate
に対し比較されるものです。例えば、2015年7月2日に発生したトランザクションは、start
および、end
をそれぞれ2015-07-01
、2015-07-02
と指定された場合に返されることになります。
これに対し、since
は、updated_at
に対し比較されます。例えば、トランザクションがdate
が 2010-01-01
のものであっても、ゲストが2015-07-02
にそのトランザクションに対し、description_guest
属性を変更した場合は、since
を、2015-07-02
とセットすれば返されます。
一方で、実際のトランザクションとシステム間において発生しうる、二つの遅延について認識する必要があります。
1つ目は、実際のデータが、トランザクション内容に、即座に反映されるとは限らないことです。例えば、ある日に、ゲスト様がクレジットカードをレストランで利用したケースを考えてみます。クレジットカードによって異なりますが、クレジットカード会社により、数日から、場合によっては一ヶ月もレストラン名が表示されない場合もあります。
2つ目は、マネーツリーがそのデータを取得する(アグリゲーションする)タイミングです。上記の場合、実際のデータがクレジットカードの会員ページに反映された後でも、マネーツリーがそのデータをタイムリーに更新取得していない可能性があります。
(強制的に更新する方法については、Request Refresh APIを参照ください。)
以上より、例えば、2015-08-02に、start
を2015-07-01
、end
を2015-07-31
とセットしてリクエストした場合でも、この期間の全てのトランザクションを取得できるとは限りません。結果として、ゲストがクレジットカードを7月31日、またはそれより前に利用した場合でも、クレジットカード会社のサイトまたはマネーツリー側でそれ以降何日か経過してもデータが入手されないことが発生し得ます。
こうした問題を対応するために、since
は有効です。since
は、指定した日以降のupdated_at
の「トランザクション全てを返します。
新しく作成されたトランザクションはupdated_at
が同じになります。また、上記の例においては、マネーツリーが7月31に発生したトランザクションを8月4日に取得したものは、since
を2015-08-04
とした場合でも取得できることになります。
Updated 9 months ago