広がりつつあるオープンデータの潮流
ここ数年でAPIという言葉はエンジニア以外でも市民権を得ており、ニュースや経済誌でも「API経済圏（APIエコノミー）」の様な用語を見かけることが珍しくない状況になりつつあります。一方で、APIではなくファイル(CSV等)によるデータ公開も広まっています。
いずれにせよ、大企業や銀行を含めた様々な企業や団体は新たな価値創造を期待してオープンデータの整備・公開を進めてきました。いまだに課題はあるものの、クローズドな印象のある大企業のデータを個人開発者でも扱えるような状況になりつつあります。
API連携 vs ファイル連携
さて、この記事では「自身がデータの提供を受ける立場」という前提条件のもとで「API連携とファイル連携のどちらが適しているか（と私が考えているか）」を主に 要件定義 の観点から記述します。書いてある内容はどれも当たり前の事ばかりなのですが、情報の整理がてら纏めてみます。企業でシステム開発の要件定義／設計に携わる人向けの内容ではありますが、個人開発者の方にも参考になれば幸いです。
この議論を別の言葉で言い換えると 「リアルタイム型連携 vs 突き放し型連携」 とも言えるでしょう。厳密には「バッチ駆動のAPI連携」もあれば「ニアリアルタイムなファイル連携」もあるので完全な言い換えにはなりませんが、大抵の場合は大きな問題のない表現だと思います。
どちらか一方が正義ということはない
結論から書くとどちらかが常に正しいということはなくケース・バイ・ケースです。大事なのは 複数の観点で検証し、どの案が「あるべき姿」に近づくのかを考えた上で最終的な判断を下すべき ということです。
どうも私の肌感覚では「APIのほうが良いよね」といった事を耳にする事が多い気がするので「いやいやそうとは限らないよ」といったトーンの記事の書き方になってしまいましたが、どちらも闇雲に否定も肯定もせずフラットに捉えています。
なお、記述をなるべく簡潔にするために 参照系 の業務を例に記述していますが、更新系業務においてもほぼ同じことが当てはまると考えています。
また、フォーマット(CSV, JSON, XML等)間のメリット・デメリットに関しては本記事で触れたい内容から外れますので、スコープ外とします。
観点1: 期待するようなデータの扱いが出来るのか
言わずもがなですが、APIは「リクエスト＆レスポンス」が対となってデータの受け渡しを行います。当然ながら「この値をキーとしてリクエストを投げて、これらの値をレスポンスとして受け取りたい」という 期待に準ずるものがAPI仕様として定義されていることが前提 になります。その前提を満たしていない場合、その目的に於いては残念ながらそのAPIを使いようがありません。
「このパラメタをキーにできれば良いのに・・・」「リクエストを投げる際にこういうオプションがあったら良いのに・・・」と思った経験がある方もいるのではないでしょうか。
一方でファイル連携の場合はデータ一式を丸ごと受け取ることになり、そのデータをどの様に扱うかは利用者側に委ねられます。無論、きちんと正規化/構造化されている必要がありますが、「どの様な条件でデータの抽出を行うのか」という点において柔軟性があるのは事実です。
観点2: 求められるデータの新鮮度（業務要件として）
API連携(この観点に於いてはリアルタイム型連携とほぼ同義とする)の場合、基本的にはデータが必要になる度にリクエストを投げる訳ですから、常に最新のデータを取得しに行くことになります。厳密にはAPI提供側のシステム仕様として、どのタイミングでデータが更新されるかに因りますが、この記事では便宜上即時反映されるものとします。
一方でファイル連携(突き放し型連携)の場合、予め定めた次の洗い替えタイミングまでの間は、当然ながら腹持ちしているデータを参照し続けることになります。
さて、大事なことはデータを利用する際、データが必ずしも最新のものであるべきとは限らないということです。もちろん「最新でないと絶対に困る」ものも多々ありますが、その逆も然りです。「最新のほうが望ましい(better)」事はあっても、業務要件によっては「最新であることが必須(must)ではない」ということもあり得るわけです。
「最新でなければならない」のか「最新でなくても良い」のか、 業務要件をきちんと見極めることが必要 です。
観点3: 提供元データの更新頻度（システム仕様として）
業務要件とは別の観点として、提供元が保有する データがどれくらいの頻度で更新されるのか という観点もあります。銀行口座や証券口座のようにミリ秒単位で更新されるものもあれば、日単位・月単位・四半期単位といった頻度で更新されるものもあります。観点2の話と似たような話になりますが、総じて「それで事足りるからそうしている」事が少なくないでしょう。
もし提供元のデータが月に１回しか更新されないのだとしたら、その間に都度APIを使ってデータを問い合わせるのは 無駄なトランザクションを発生させている とも言うことが出来ます。
データ提供側のシステム仕様を理解することが必要、ということです。
観点4: 求められるTAT(turn around time)
無線区間を含む通信経路の高速化が進んでいる現在に於いても、一部の案件では厳しいTAT要件(数十msec〜数百msec)が求められることもあります。ファイル連携により予めデータを腹持ちしている場合は、基本的には自システム内の処理に要するTATを考慮すれば良いのですが、都度データを問い合わせるAPIを利用する場合は [データ依頼側システム]<====>[通信経路]<====>[データ提供側システム] という経路を介する訳ですから、その区間TATが加わることになります。
無論、こうしたクリティカルなシステムの場合は経路上の工夫（専用線化など）も併せて検討する訳ですが、観点として意識しておいたほうが良いと思い記述しました。（経路上の話も色々と触れたいですが、話が発散してしまうので割愛します。）
観点5: 障害発生時の影響範囲
観点4に続きSLAに関わる大事な観点の一つです。観点4にも記載の通り、当然ながらAPIを利用するということは、 経路上や外接システムにて障害が発生した際に、その影響を被る可能性が高い ことを意味します。
どういった影響があるのか（あるいは無いのか）は、全体のシステム構成や外接システムの定めるSLAにも因って変わりますが、場合によっては全断もあり得ることを予め念頭に置いた上で、要件定義や運用設計を検討する必要があります。
※繰り返しになりますが、ファイル連携を一方的に支持している訳ではありません。API連携時でも設計上の工夫次第ではこうしたリスクを低減することが可能です。あくまでこの様な観点を考慮すべきだということを述べているまでです。
全体を俯瞰した上で要件定義を
API連携とファイル連携、一見単純な話に見えても様々な観点から考慮すると どちらが優れているとは一概には言えない ことが分かるかと思います。こうした観点を踏まえて業務要件定義／システム要件定義を進め、まずは「あるべき姿」を描いた上で、最終的な落とし所をさぐるのも、一つの進め方として間違ってはいないと私は考えています。バズワードやトレンドを学ぶことは大事ですが、それに流されすぎることなく、ちゃんとした 「目利き」 を行いたいものですね。