最近のAPIはJSONを基本フォーマットとして提供していることもあり、Webアプリケーションから利用したいという要望が強くなっています。しかしWebアプリケーションでのAPI利用は、サーバサイドとは異なる問題点が幾つもあります。
非同期
Webアプリケーションの場合、基本的に利用する言語はJavaScriptになります。JavaScriptはシングルスレッドな実装なので、ネットワークやデータの処理に時間がかかるものを同期処理にすると、処理が完了するまで全く何も操作できなくなってしまいます。それを防ぐためにJavaScriptは非同期で実行されます。
非同期処理においては何かの処理完了を待ってから次の処理につなぐといった動作をする際にコードがネストしながら書くことになります。現在、Promiseやyield、syncといった新しい技術も開発されてきていますが、APIとのデータ送受信は非同期処理であることを強く意識する必要があるでしょう。
CORS
Webブラウザはセキュアな設計を重視しています。そのため表示しているサイト以外のデータを利用するのに対してセキュリティ上の制約がたくさんあります。特にプログラマブルなAjaxについてその傾向が強くなっています。
GETであればJSONPが使えますが、POST/PUT/DELETEといったメソッドについてはサーバ側でCORSがサポートされている必要があります。逆にサーバ側の設計としては無制限にCORSを許可するのはセキュリティ上のリスクになるということを把握しておく必要があります。
キーの隠蔽
APIの利用に際してキーを使う場合、そのキーが漏洩しないように注意しなければなりません。HTMLやJavaScript上に定義するのは問題です。多くの場合、Webサイトのドメインとキーの組み合わせで制御しています。
安全な方法としてはOAuth2でドメインを使って制御するのが良いでしょう。また、提供側としてはトークンの再生成機能を用意しておくのも必要です。
認証
Webアプリケーションではキーの完全な隠蔽が難しいので、認証においても注意が必要です。OAuth2を使うのが良いですが、場合によってはトークン認証を使うかも知れません。トークンが漏洩すると外部からデータ操作が可能になってしまうので注意が必要です。
Basic認証はID/パスワードの入力が必要になるのでお勧めしません。APIと関係なく認証だけを使いたいのであれば、OpenIDを使う方法も考えられます。
コードが公開される
JavaScriptの最大の難点としてはソースコードが公開されてしまうことでしょう。難読化することもできますが、逆に可読性を回復させるソフトウェアも存在するので大した意味はありません。
現在、ウェブアセンブリとしてJavaScriptをコンパイルする技術も開発が進められていますが、標準化するのはまだまだ先でしょう。そのためソースコードは誰かに見られても大丈夫なようにしておく必要があります。
Webアプリケーションの場合、サーバサイドで使うのと違う点としては、
- 利用主体がコンピュータ（サーバ）/人（Webアプリケーション）
- ソースコードが見られない（サーバ）/見られる（Webアプリケーション）
が挙げられます。相違点を適切に把握し、セキュリティに配慮した利用が肝要です。提供側としては、利用主体の違いによって提供するデータであったり、方法を選定する必要があるでしょう。
