企業がAPIを使う側に立った時、それは一つのAPIだけを使うとは限りません。APIでは複数のAPIを組み合わせるマッシュアップと呼ばれる形態が存在します。同じ市場に存在するAPI同士を組み合わせることで、API提供元ではできないサービスを提供できる可能性があります。有名なところではホテルや旅行の検索アプリケーションが挙げられます。
そうした複数のAPIを組み合わせて使う場合、問題になるのがネットワークの遅延であったり、API停止に伴うマッシュアップサービスへの影響です。今回はそうしたマッシュアップ時における問題点と解決策を紹介します。
フロントエンドではAPIを処理しない
JSONやRESTfulでのAPI提供を行っていると、WebブラウザのJavaScript側でデータを取得したり集計できるようになります。そのためWebブラウザだけで処理を完結させたいと考えることでしょう。その方がサーバサイドの仕組みも用意しないで済みますし、簡単です。
しかし各APIが密に結合している場合、一つのサービス停止が他のサービスに影響を及ぼすのは避けなければなりません。そこでデータの収集をサーバサイドで行い、データベースに入れておくことでデータの参照はいつでもできるようになります。
なお、APIによってはサーバサイドでの蓄積を禁止している場合がありますので注意してください。また、OAuth2のような仕組みを使っている場合、サーバサイドでは認証データがなくて目的のデータにアクセスできないことがあるので注意が必要です。さらにFacebookなどのOAuth2トークンは有効期限が決まっており、常にデータアクセスができる訳ではありません。
データの取得はバックグラウンドで
さらにユーザのリクエストに応じてAPIを叩くのではなく、APIへのアクセス処理はバックグラウンドで行うようにしましょう。APIからのレスポンスがないと何も表示されない状態が続くのは避けるべきです。
また、一旦キューに入れてレスポンスを返す仕組みであれば、何らかの原因でAPIアクセスがエラーとなった場合も再実行しやすくなります。ユーザからの入力をそのままAPIに渡す場合、エラーが出てしまうとユーザは再度入力を強いられることになるでしょう。
データの取得中はユーザ向けにはインジケータを表示するようにしましょう。まず画面の表示だけ行ってしまって、データの取得ができ次第画面を更新するようにすればストレスは小さくて済みます。
データを疎結合にする
APIを密に処理してしまうと問題が発生しやすくなります。A -> B -> Cの処理の流れがあった時に、AまたはBに不具合が発生するとCの処理は全くできなくなってしまいます。そういった事態を防ぐためにAPIはそれぞれを疎結合になるように設計しましょう。
APIの多くはHTTP/HTTPSでアクセスをします。つまり、3つのサービスを使っていて、それぞれが100msでレスポンスを返したとしても3つを密結合で使っていたら300msかかってしまうということです。
疎結合にできると各サービスへの接続が平行に（パラレルに）行えるようになります。3つのAPIを扱う場合も、同時にアクセスできれば100msでレスポンスが得られるようになります。
更新頻度の違いに注意
APIによって、データが刻々と変わるタイプとそうではないものがあります。一度取得してしまえば数ヶ月アップデートされないものもあるでしょう。例えば郵便番号から住所を返すものは、月一回くらいでしかアップデートされませんし、一年に一回しか取得し直さないとしてもワークフロー上大きく困ることはないでしょう。
そうしたデータの種類と更新頻度は注意が必要です。常に最新のデータを必要としないケースも多々ありますので、キャッシュを有効に使うのが良いでしょう。
APIはボトルネックになりがちです。データベースはシステム内部に構えられますが、APIは処理やパフォーマンス自体ブラックボックスになりますので明確に保証されるものではありません。APIがなければできない処理があるのも確かですが、頼り切りにならないよう注意しましょう。
