自分のページができた。情報を保存する場所も見えてきた。

次に欲しくなったのは、自分の手元にはない情報だった。

KAZU「ページに甲府の天気を出したい。」

Python「天気の情報はありますか？」

KAZU「窓の外は見える。」

Python「明日の分は？」

それは困る。明日の空は、今の窓から見えない。

そこで登場するのがAPIだ。

API「天気情報を提供するサービスへ、決められた方法で問い合わせることができます。」

KAZU「外へつながる道路ってこと？」

API「そのイメージは役立ちます。ただ、道路の先には受付があります。」

好きなところへ勝手に入って、欲しいものを持って帰る仕組みではない。どの窓口へ、どんな形式で頼むかが決まっている。

たとえば「甲府の天気」を頼むつもりでも、相手は都市名ではなく緯度と経度を必要としているかもしれない。

KAZU「『甲府です、よろしく』じゃ駄目なの？」

API「受付が受け取れる形にしてください。」

このように、プログラム同士がやり取りするための窓口やルールがAPIだ。この話ではインターネット経由のAPIを扱うが、APIという言葉自体は、もっと広い場面でも使われる。

返ってきた情報は、そのまま完成した天気画面になるとは限らない。気温や天気のコードなどを受け取り、自分のページ側で文字やアイコンにして表示する場合もある。

つまり、「情報をもらう仕事」と「見やすく見せる仕事」は、分けて考えられる。

KAZU「食材が届いても、料理はこっちでする感じ？」

API「そのたとえなら分かりやすいですね。」

また、サービスによっては利用登録や認証、料金、回数制限がある。必要な鍵の扱いもサービスごとに確認する。秘密にするべきキーを、誰でも読めるHTMLやJavaScriptへ書いてはいけない。

道路が一本できると、外の力を借りられる。ただし、相手の受付時間やルールを無視して走れるわけではないのだ。

【ミニテスト】

APIから天気のデータを受け取ったら、必ず完成した天気画面も一緒に届く？

A．必ず届く
B．データを受け取り、自分で画面を作る場合もある

答え：B。何が返るかは、そのAPIの仕様による。

【小さな実習】

「外からもらいたい情報」を一つ考えよう。次に、それを「自分の画面でどう見せたいか」も書いてみよう。取得と表示を分けると、必要な仕事が整理できる。