APIが生み出す複雑性とその回避法

APIを多用して開発を進めていると、次第にシステムが複雑になってくるのが実感できるはずです。要因を挙げつつ、その回避策を紹介します。

APIの種類の増加

データを検索、加工、保存、外部への通知など様々なデータソースに対してAPIリクエストを行っていると、その管理が煩雑になってきます。最も大きなリスクとしては、一社のサービスが停止した場合に処理全体が止まる可能性があることでしょう。また、契約も複数企業と行うことになり、サービスレベルの統一も難しくなります。

回避策として、多くの企業ではなく一社にまとめてしまうという方法があります。特定企業だけが提供する機能である場合は難しいですが、クラウドサーバのような汎用的な機能であれば選定先は数多く存在するでしょう。そうしてAPI提供企業を絞り込むことで、サービスレベルの統一が可能になります。依存リスクは高まりますが、元々使っているAPIがあるのであれば一定のリスクは存在するでしょう。

ネットワーク接続先の増加

APIは一般的にHTTP/HTTPS接続によって提供されるので、実行するAPIが増えればその分、ネットワークの接続先が増えていきます。ユーザからのリクエスト、サーバからAPIのコールとその結果待ち、そしてユーザへのレスポンスと複数のネットワークコールが行われると、その分レスポンスが遅くなってしまいます。

回避先として、JavaScriptベースのAPIがあればユーザブラウザから直接コールしてもらうという方法があります。そして、ユーザが受け取った結果を自社サーバに転送してもらうのです。

ネットワーク遅延に伴う実行速度低下

APIで最も問題になるのがネットワークの遅延です。特に複数回APIをコールしなければならない状態において、一つのAPIコールの結果を待って処理しなければならない場合は大きな問題になります。

こうした問題はAPI同士が密結合することによって起こります。しかしAPI自体はなるべく疎結合になっているべきで、システムの設計上問題があるかも知れません。また、ネットワークアクセスはnode.jsのように非同期実行できる言語を採用したり、バックグラウンド処理に回すことでユーザレスポンスを改善できる可能性があります。

サービス終了に伴うリスクの増加

APIを使う上での最大のリスクと言えます。これを回避するのは契約上の縛りと、代替サービスを平行して使う方法があります。

ビジネスで使うAPIであれば、SLAの保証は適切に行われなければなりません。その意味において、無料で提供されるAPIほど怖いものはないでしょう。無料だからと気軽に使っていると、API提供側もビジネスとして成り立たず、突然終了する可能性があります。

代替サービスを常に探しておくのも大事です。世の中には数万のAPIが存在しており、類似APIは多数存在します。ただしインタフェースが異なるケースは多いので、APIコール部分をラッピングし、代替サービスへの乗り換えを容易に行えるようにあらかじめ準備しておくのが良いでしょう。

一旦複雑化したシステムをリファクタリングするのはそうそう簡単なことではありません。あらかじめそうしたリスクを勘案し、設計やコーディングに反映しておくのが大事です。