API

おいしいパスタを食べにレストランへ行ったときのことを思い浮かべてみましょう。私たちは厨房に入って冷蔵庫を開けたり、コンロに火をつけたりはしませんよね。

席にゆったり座ってメニューを眺め、店員さんに食べたい料理を伝えるだけです。すると店員さんが厨房のシェフに注文を伝え、できあがった料理をテーブルまで運んでくれます。

スマホアプリの世界でも、まったく同じことが起きています。天気アプリが気象庁の巨大なコンピューターシステムの中を自分で探し回る必要はありません。店員さん役の決められたやり取りの窓口に、「今日の東京の天気を教えて」と決まった形式の注文書を渡せばいいのです。

すると相手のシステムが天気の情報をきれいにまとめて、アプリの画面に表示してくれます。このように、プログラムの間で注文を受け付け、結果を返すルール全体のことを指します。

新しいショッピングアプリを作るところを想像してみてください。決済システム、地図画面、本人確認機能まで、最初から最後まで一人で作ろうとすると、何年もかかるかもしれません。

でも、すでによくできた金融機関やポータルサイトのシステムを借りられるなら話は変わります。地図会社が公開している規格に合わせてリクエストを送るだけで、アプリの中に素敵な地図が魔法のようにすっと収まります。

他の人が何年もかけて完成させた大きな技術を、まるでレゴブロックのように持ってきてつなげることができるわけです。おかげで開発者は、車輪の再発明に時間を無駄にせず、新しいサービスづくりに集中できます。

毎日使っているフードデリバリーアプリが、地図と決済と配車のシステムをあっという間に組み合わせて動いているのも、すべてこのつなぐ技術のおかげです。

他人に自分のシステムを勝手に壊されたらどうしよう、と心配になるかもしれません。でも、厨房のドアを全開にするのではなく、店員さんの窓口だけを開けておく形なので、中身を守るのはずっと簡単です。

よく設計されたAPIは、許可された質問だけを受け付け、内部の大切なデータベースへ直接アクセスされるのを防ぎます。ただし、認証や権限チェックに抜け穴があると、API自体が攻撃の入り口になってしまうこともあります。さらに、内部のプログラムを全面的に作り変えても、外から見える注文ルールさえ同じに保っておけば、つながっている他のアプリは壊れずに動き続けます。

もう少し正確に言うと、単に機能を借りる道具にとどまらず、「プログラム同士の安全な契約」です。やり取りするデータの形式や通信方法は、REST のように広く使われている方式に合わせて設計されることが多いです。