前回、「クライアント・サーバ」について、初歩的な考え方を紹介しました。
今回は、この「クライアント・サーバ」が、最近のフロントエンド開発、JavaScriptやそのフレームワークと、どのように連携して動くのかを紹介します。
SPA(Single Page Application)やスマホアプリはクライアント・サイド
前回紹介した「SPA(Single Page Application)」あるいは、スマホアプリは、「クライアント・サーバ」の概念の中ではクライアントにあたると考えます。
たとえば、SPAを実現しやすい技術として紹介した、JavaScriptフレームワークの「React」は、以下のような形で動いています。
「React」のソースコードには、HTMLやCSSを書き込むので図で表すと微妙な感じになりますが、とにかくWebクライアントであるブラウザ上で動いています。
「React」で書かれたプログラムは、動的にサーバ上から情報を取ってきては、画面表示を書き換える、ということを繰り返します。
サーバサイドで動く「API」
「React」つまりクライアントから呼び出されるサーバ上のプログラムを、普通「API」と呼びます。
「API:Application Programming Interface」とは、ヒトが見るためではなく前述の「React」あるいは「JavaScript」などでできたプログラムが、情報をやりとりするための仕様(インタフェース)です。
厳密な言葉の意味は、仕様(インタフェース)なのですが、サーバ上で動いているプログラムそのものを「API」と呼ぶことが多いです。
スマホアプリの場合
スマホアプリの場合も、SPA、あるいは、Reactの例と同じようにAPIと通信します。
スマホアプリの場合、その内部でブラウザを動かすこともよくあります。その場合は、前述のブラウザの例と同じことが、スマホアプリの内部で起こっていると考えればよいです。
APIの正体
サーバ側で動く「API」のプログラムは、どんな言語で書かれていてもかまいません。クライアント側のアプリやJavaScriptはそれを知る必要はありません。
お互いに知っていなければならないのは、
- どういう形式で入力して、
- どういう形式が出力されてくるか、
ということだけです。この仕様を一般に「インタフェース」と呼びます。「インタフェース」とは、何かと何かがつながる部分を指す、概念的な言葉としてよく使われます。
出力データの形式は、次の2つがよく使われます。
- JSON
- XML
「JSON」はクライアント側の解釈作業が、「XML」よりカンタンになるため、よく使われるようになりました。
2005年頃、「Googleマップ」が登場して、JavaScriptがAPIとデータをやり取りする「Ajax」が一世を風靡しましたが、「Ajax」は「Asynchronous JavaScript + XML」の略なので、このときはXMLが使われていたことがわかります。
APIの事例:「Googleマップ」のAPI
APIは、プログラムとプログラムがやり取りするための仕組みなので、普通、画面に表示されたりしないので目に見えず、わかりにくい印象があります。
もっとも有名なAPIは、「Googleマップ」のAPIです。
JavaScriptを書くだけで呼び出せるAPI(Maps JavaScript API )が用意されており、カンタンに使えます。
前述のサーバ側のデータを呼び出す形のAPIは、たとえば「Geocoding API」がイメージしやすいです。
どんな形式で入力して、どんな形式で出力されてくるのか、サンプルが出ています。
まとめ
クライアント・サイドのプログラム開発について、「クライアント・サーバ」の中での概念的位置付けとその事例を紹介しました。
お役に立てば幸いです。
コメント