1. マルチデバイス、マルチプラットフォーム
今やAPIはWebアプリケーションに限らず、スマートフォンやタブレットアプリ開発においても欠かせぬ存在になっています。そのため元々WebアプリケーションをAPIを使って開発しておくことで後々のスマートフォンアプリへの対応も同じAPIを使って開発ができます。同様にWindows/Mac OSXなどの異なるプラットフォームへの対応も行えます。
もちろんプラットフォームによって対応できる機能の違いはあります。特に認証や課金周りは仕組みが違うことがあります。しかし予め分かっている場合は各プラットフォームに縛られる技術ではなく、汎用的なAPI設計にしておくのが重要でしょう。
2. フロント/バックエンドの疎結合化
従来のWebシステム開発の場合、サーバサイドでHTMLをレンダリングしていましたが、それによってフロントエンド（見た目）の回収はサーバサイドのシステムへの修正が必要でした。フロントエンドとバックエンドがAPIによって疎結合化することでそうした面倒さはなくなり、HTMLではなくJSONやXMLのように授受されるデータフォーマットを基にした仕様決めが可能になります。
なお、この手の場合常に話題になるのがSEO対策ですが、主に2つの解決方法があります。
- クローラー向けにサーバサイドレンダリングにも対応する
- moviepilot/seoserverのようなソフトウェアを用いる
1についてはサーバサイドとクライアントサイドでテンプレートが重複してしまうのが問題です。そのため、例えばReactを使うことでサーバサイドとフロントエンドで共通のテンプレートが利用できるようになります。2の場合は特定の技術に依らずに使えるのがメリットですが、表示処理に多少時間がかかってしまうのが難点です（最近のGoogleクローラーは表示までの速度をランキング上のパラメータにしているという話です）。
3. サーバサイドの改修コストを抑える
APIはURL単位のマイクロサービスに分割することが可能です。そのため、将来的にフレームワークのバージョンを上げたり、プログラミング言語自体を変えたいと思った場合、一部の機能だけ問い合わせ先のアプリケーションサーバを切り替えると言ったことが容易にできます。これはAPIの先はブラックボックスになっているメリットと言えるでしょう・
最近の技術革新は速く、最新のフレームワークに乗り換えることで開発効率が大幅に向上したり、実行速度も格段にあがります。そうした中、既存のシステムが足かせになってしまうのは大きな問題で、かといったすべてを乗り換えるコストはとても大きいものになります。APIを使うことで一部から順番に移行していくことが可能になります。
4. 処理の単純化
RESTfulな設計を行っている場合、一つ一つのアクセスはそれぞれ一つのモデルに対する操作になります。そのためロジックが複雑化せず、一つ一つのリクエスト処理は高速に実行できます。これはクライアント、サーバ双方にとってのメリットです。ただし複数のデータを組み合わせて処理する場合、リクエスト処理が増えてしまうのが問題になります。ネットワークのレイテンシーは無視できないほど大きいため、ロジックをシンプルにするのとネットワークアクセス頻度は常にトレードオフになりえるでしょう。
解決手段の一つとして、一つのリクエストの中で複数のURIを含めるバッチ処理をサポートするという方法があります。実際にはWebサーバがプロキシになってバッチ処理をアプリケーションサーバに投げて、その結果を一つにしてクライアントに返却するというものになります。これによりサーバ側とクライアント側両方のニーズが叶うでしょう。
5. 将来的な追加開発コストの低減
システムの開発コストを引き上げるものは複雑性です。特に追加開発時は複雑なものに対していかに後方互換性を失わずに開発するかに頭を悩ませることになります。そして度重なる追加開発の結果としてバグが入り込むことになります。
APIの構造をシンプルに保てれば、それだけ追加開発のコストを下げることにつながるでしょう。シンプルであれば保守性もよく、バグが混入する余地も小さくなります。APIファーストな設計はシステムライフサイクルをスムーズにします。
6. 外部企業とのシステム連携が容易に
他の企業とのシステム連携を行う場合、必ずAPIが必要になります。連携が決まってから開発していると時間がかかるのはもちろん、その個別企業との取引に最適化されてしまうことがあります。その結果、別な企業との連携が必要になるとまた一から開発し直しになります。
予めAPIがあることで連携が容易になるのはもちろんのこと、万一追加機能が必要であっても元々の設計標準に従って開発することができます。それは個別の企業に特化せず、汎用的かつ安全性の高いAPIになることでしょう。
7. 高スケーラビリティ
一つのサーバでHTTP/アプリケーション/データベースを提供し、かつサーバとクライアントサイドが密接に関わっている場合、どこがボトルネックになっているのか調べるのは困難です。またボトルネックが分かったとしてもスケールさせる際にはシステム全体の設計を考え直す必要があるかも知れません。
APIファーストの場合、元々サーバサイドとクライアントサイドが分離しています。その結果、どこがボトルネックになっているかが分かりやすく、かつ一般的にAPIは単一のURIで提供されますのでスケールしやすくなっています。
いかがでしょうか。今後、スマートフォンやタブレットはエンタープライズにおいても一般化していきます。そうした中でそれぞれ個別に開発していては時間もコストもかかりすぎてしまいます。APIを最初に設計、開発しておくことで将来的な広がりが容易に実現できるようになるでしょう。
また、サーバ/クライアントサイドを疎結合にすることで保守性を高めたり最新技術への追従も容易になります。今後システム開発を行っていく際にAPIファーストに進めてみてはいかがでしょうか。
