どうも！ひよこSE（@PiyoOct）です。
APIって何？
APIをひとことでわかりやすく言えば、「異なるシステムの間に入る窓口的な存在」です。
「異なるシステムの間に入る窓口」って言われても、ピンとこない・・・ですよね。
「よくわからんなぁ～」ってなった時は、具体例を見ながら覚えるのがよき。これからきちんと説明します。
APIとは、異なるシステムの間に入る窓口的な存在
APIとは、「異なるシステムの間に入る窓口的な存在」とまずは、呪文のように唱えながら・・・。
レジとキャッシュレス決済の間みたいに、異なるシステムの窓口になる
例えば、レジでお金を払うときによく使う、キャッシュレス決済は、たぶんAPIが使われています(実際に開発した人間ではないので、「たぶん」になるけど、だいたい合ってると思う(*´ω｀))。
レジのシステム⇔API(窓口)⇔キャッシュレス決済(Paypayとか)のシステム
- レジの「金額を計算/レシート出す」的なシステム
- キャッシュレス決済の「タッチしたら支払いがされるよ」的なシステム
のように、レジとキャッシュレス決済のシステムは、全くの別物。
その証拠に、キャッシュレス決済を導入していない店舗もたくさんあるわけで・・・。
レジでキャッシュレス決済を使えるようにしたいなぁ～
とお店が思うからこそ、お客さんが使うことができきす。
そのときに、まさか、レジのプログラムを変えるのは面倒だし、お金かかるし・・・で。
そんなときは、APIが２つのシステムの間に入って、やりとりができるように窓口的な役割を果たします。
「アプリケーション」と「プログラム」の接点
ちなみに、APIは英語で書くとこんな感じ。
- A：Application（アプリケーション）
- P：Programming（プログラム。「元のプログラム」って思えばいいかも）
- I：Interface（接点・コンセントの接続口）
なんとなく、くっつけると「アプリケーションとプログラムの接点」です。
ちょいと意訳して、「異なるシステムの間に入る窓口」とひよこSEは解釈しています(*´ω｀)。
※P：Programmingからみたら、A：Applicationは全く別のシステム。その逆もしかり。この解釈で行くと、「A：キャッシュレス決済、P：レジのシステム」。AをPで使えるようにしたいからAPIみたいな感じで・・・。うまく説明できないや。ごめん 笑。
APIの例
APIの例について、レジとキャッシュレス決済以外に、いくつかピックアップします。
繰り返しになりますが、「たぶん」です。
ただ、Nintendo Switchと、スマホアプリ（ピカブイと、ポケモンGO）のように。
異なる世界であるはずのシステム同士が、つながっているように見えるのは、APIと呼ばれるプログラムが、窓口的な役割をしてくれている可能性が高いですね。
APIのメリットは？
APIのメリットは、「異なるシステムの窓口(=API)を使って、なんかしたら、おかしくなりました」ってなったときに、APIのプログラムだけを直せば修正が完了すること。
え？どういうこと？
そうですね。例えば、Nintendo Switchからスマホアプリに、なんかのデータを送ったときに。
スマホアプリ側のデータがおかしくなったとして、その原因が窓口役のAPIだったとします。
このときに「Switch側と、スマホアプリ側のプログラムの修正は必要か？」といえば、不要です。
APIがおかしいのならば、APIのプログラムだけを直せばいいわけで。
Switchとスマホアプリ側は、直した後のAPIのプログラムを読み込みなおして、再リリースし直すだけでいいわけです。
Switchのプログラムと、スマホアプリ、それぞれの本体のプログラムを触ると、何があるかわからないから、なるべく手を加えたくないわけです！
これを試験っぽく書くと、メリットは下の通りだったりします。
- 開発が効率化される
- 開発工数が削減される
⇒どこを直せばいいかがわかりやすいし、修正も少なく済む - セキュリティが向上する
⇒異なるシステム同士は、APIだけが接点なので、不具合も起きにくいし安全性が担保される
まとめ
APIときたら、「異なるシステムの間に入る窓口的な存在」だと思ってください。
システム的には別の世界なのに、いろんな便利機能がつかえるとしたら、ほぼAPIのおかげです。
ふんわりとした言葉で、理解しづらいかもですが、そんなもんだと思ってくださいまし(-_-;)。
コメント