Web API への期待と現実のギャップと克服のための3つの理解

## API の過大な期待
「Web API とは外部とのデータ連携を可能にする機能です。」という説明は正しいです。Web API は、サービスやアプリ内のデータをURI という形で公開して、GET / PUT / POST / DELETE のメソッドで外部から呼び出し、データをJSON やXML で返すものです（一般的にRESTful な説明）。
ところが、従来から「データ連携は、(ASTERIA Warp やDataSpider のような)EAI ツール」というイメージが強く、API はデータ連携のための機能なら、「API は、EAI 機能なんだ」ととらえている方が多く存在します。そのため、API は魔法の杖のように「API があれば何でもできる」と主にビジネス側の方から思われてしまっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116843/d7cc255e-9173-18ac-eaaf-b4956bcaf1ac.png)

この記事では、API 連携という言葉の理解にビジネス側とエンジニア側で大きな隔たりがありそうだということを知ったうえで、両者が最低限何をコミュニケーションすれば相互に話ができるかを考えてみました。


## そもそも「連携」って言葉の範囲が広くない？

英語でデータへのアクセスや接続に絡む言葉をあげてみましょう。日本語になるとどうやらすべて「連携」と訳されてしまうようです。Interface でもConnect でもIntegrate でもすべて「連携する」「連携」と訳されるこの不思議。実は我々も英語の技術資料を日本語訳して、すべて「連携」でよいのだろうかと悩むのですが、やはりしっくりくるのは「連携」です。Google さんのSEO が引っ掛かるのは「連携」です。

* Interface = 接続する部分・使用、連携
* Connect = 接続すること、連携
* Access = アクセス、接続すること、連携
* Integration = 統合すること、連携
* Sync = 同期すること、連携
* パイプライン　= 接続してデータを移動させること、連携
* File Upload/Download = ファイル連携
* ETL ツール = データ連携ツール
* EAI ツール = アプリケーション間連携ツール

「連携」は、システム用語として定着する以前から、企業の部署間の協業であったり、スポーツの守備範囲の受け渡しであったり、「連携といっておけば詳細は定めなくてもうまいことやってくれる」という素晴らしい言葉でした。システム間のデータ接続・統合に「連携」が使われだしたのはいつからなのか知りませんが、日本ではシステム連携という言葉が上のどの訳語よりも定着しています。

類似の言葉に「つなぐ」という言葉もあります。これも便利なことばです。何やらA とB という点があって、一本の線で両方を結んでいるイメージです。この言葉もイメージの良い言葉です。なにやら絆みたいで、両者が握手をしているようです。

## 実際にA というサービスとB というサービスの両方をAPI で連携しようとすると

では、実際にA とB という二つのサービスにAPI が公開されているとして、連携をしてみましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116843/625d96b6-38e2-51fd-f4cd-c4298fdbf947.png)


エンジニアではない方の多くは、API = データ連携ツールだと思っているので、A とB のシステムを線でつないで完成します。線というよりお互いから右手が出ていて握手するようなイメージだと思います。当然リアルタイム・双方向連携のイメージに違いありません。「API があるから何とでもがっしり連携できますよ。」とWeb API 昨日を提供するクラウドサービスのマーケティング資料のポンチ絵にも書いてあります。

一方、実装するエンジニアの方からすれば、Web API は呼び出しのための仕様であり、A とB それぞれのAPI の呼び出しを行うモジュールが必要で、異なるA とB のデータ構造やモデルを考慮したり、ロジックとして重複データなどを処理して、定期実行をセットして・・・と長い連携処理をプログラミング必要があります。

おそらくそのギャップたるや10倍ぐらいは感覚としてあるのではないでしょうか。よくビジネス側の方が「ウチのエンジニアはAPI に疎くて、できないとばっかり言うんだ」とぼやいたりしますが、エンジニアサイドは実はAPI を使えて、必要な工数を出した結果が想定より10倍になっていて。実は、API に疎いのはビジネス側だったりするケースもありそうです。

では、そうすればこのギャップを埋めることができるのでしょうか？ビジネスサイドとエンジニアサイドが同じ土俵で話ができるように少なくとも以下の相談をするようにしましょう。

3つの簡単な質問です：1. API を呼び出すシステムは何？、2. API 連携の方向は？、3. API 連携のタイミングは？　

## 1. API を呼び出すシステムは何？

### API は受動的で自分で他のAPI とはつながらない

API はあくまで「呼び出されるためのインターエース」です。お互いに他のAPI と握りあったりするような手はありません。また、「相性が良ければつながるだろう」ということもありません。雄と雌、プラスとマイナスではありません。API はひたすら外部プログラムからAPI が呼び出されることを待つだけです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116843/50ace840-29cd-69ff-8f08-fad1cdb41fc9.png)

### 「別のシステム」は誰？

もしA とB というシステムを連携する場合にA のAPI もB のAPI も待っているだけで仕事をしてくれないのであれば、別の「API を呼び出すシステム」が必要になります。呼び出すシステムと言いましたが、実際にはAPI を呼び出すだけではなく、上で説明した多くのデータ連携のための仕事をするのですが。

API 連携の間に入るシステムとしては、カスタムで作られたプログラムである場合があります。また、ASTERIA、DataSpider、Informatica などのETL/EAI ツールが担う場合もあります。この場合はETL/EAI ツールが連携対象となるAPI をサポートしているかを事前に確認する必要があります。ETL/EAI はAPI の連携がもともとできるツールなのではなく、API 呼び出しを行うためのプログラムをETL/EAI 側がコーディングで実装しているのです。他にもクラウドサービスとして提供されるデータ連携サービスであるiPaaS も出てきています。Zapier、IFTTT、国内だとAnyflow のような。これらの場合にも同様に元々iPaaS がどんなAPI とでも連携できるのではなく、iPaaS ベンダーがAPI コーディングを実装しています。

幸運であれば、A かB のサービスがWeb API の公開以外に、他のAPI を呼び出す機能を内包している場合があります。この場合はラッキーです。ユーザーは労力なくして、A とB とのデータ連携をエンジョイできます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116843/53121025-a698-9819-69c9-89f70c875a90.png)

## 2. API に双方向同期はない～連携の方向は？

次にA とB のデータ連携とは言っても、A のデータをB に入れるのか、B のデータをA に入れるのかは重要です。システム連携では「うまいこと双方向で連携」というものは幻想です。もし、データが双方向で連携するのであれば、それは、A → B という連携と、B → A という連携があるだけにすぎません。データ連携を語るときには連携の方向（どっちのデータをどっちにいれるか？）は不可欠な情報です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116843/fac4cebb-7506-dfb4-6e93-49cf3d2e814d.png)

今回の絵では、A とB がどちらもAPI を持つサービスですが、A がAPI を持つサービスで、B がカスタムアプリ、ツール、DB であるケースもあります。この場合は特にこの方向によって難易度が大きく変わります。例えば、「BI ツールとSalesforce を連携する」といったときに、「Salesforce データをBI ツールで使う（Salesforce → BI）」と「BI で貯めて加工したデータをSalesforce で使う（BI → Salesforce）」では、システム連携の方法が全くことなります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116843/8febf820-0257-4686-9c73-c6684464d846.png)

## 3. API はリアルタイムが苦手～API 連携のタイミングは？　

API 連携というと、「インターネットなんだからリアルタイムでしょ？」と思われる方が多いです。ただし、実のところ、A とB のデータ連携はリアルタイムには向かないものです。リアルタイムで行われるのは、API 連携を行うプログラムからAPI が呼ばれた時にリアルタイムなデータが返ってくるというだけです。A に変更があった場合に、リアルタイムでB に変更を反映するということはWeb API には不向きです。これはWeb API がデータ連携を能動的に行っていないためです。まあ、Webhook は能動的ですが、今回は除外して考えます。

通常はリアルタイムとは言っても数分や数時間おきにAPI 連携システムから「新しいデータあるかい？」もしくは「全部データ頂戴」とデータを呼び出しに行っているだけです。このインターバルが短ければ短いほど連携の難易度は一般的に上がります。API のコール数が多く使うし、やり取りするデータ量も大きくなります。

盲目的に「リアルタイム」というとドンドン難易度やコストが上がります。定期実行や、データを使うときに連携ボタンを押すなどの実装でよい場合も多くあると思います。

## まとめ
エンジニアチームや、データ連携ベンダーとの会話もこの3点を抑えれば大変スムーズに進みます。もちろんほかにも考慮する点はありますが、達成したいデータ連携のイメージが2点を線で結んだような連携から、実現可能なシステム連携に近づきます。

API 連携でビジネス側とエンジニア側で違和感があるなと思われた方は、是非こちらをお試しください。

弊社は[CData Software](https://www.cdata.com/jp/) といって、カスタムシステム、ETL/EAI ツール、iPaaS、BI ツールなどからのAPI へのアクセスを実現するドライバー・コネクタを提供しております。弊社へのお問い合わせの際は、是非上記3点の情報を添えていただきますと、スピーディにサポートができます。よろしくお願いします（そこかよ？）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/116843/ecb6c1ea-a572-9c9e-8261-435805e277e1.png)