これから、新しい連載をはじめるよ！！
はじめに
この連載では、以下の内容を解説する予定です。
- APIとは何か。
- まずはシンプルなAPIを作ってみよう（別名、初心者でもできるAPI作成）
- 既存のCCコンピュータAPIを見て、コツを学ぼう
- 色々なAPIを作ってみよう
まず、連載の初回なので、APIって何？ という根本的なお話からしたいと思います。
まずはAPIの定義。
API（Application Programming Interface）とは、「プラットフォーム側のプログラムがその機能をアプリケーションプログラムから利用できるように公開したインタフェース」です。
これだけだとさっぱりですね。詳しく解説しましょう。
まず背景について
プログラミング初心者のために、このAPIという言葉の背景を説明しましょう。
現在のほとんどのアプリケーションは、一つのプログラムだけでその機能の全てを実現しているわけではありません。
たとえばMicrosoft Office Wordには特定のフォルダにある文書ファイルを開く機能がありますが、この機能はプログラマが一から作ったわけではなく、OSであるWindowsが提供する機能を利用して実現しています。
このように現在の多くのプログラムは他のプログラムの機能を利用して作られています。
プラットフォームについて
ここでのプラットフォームとは、ソフトウェアが動作するための土台という意味で使っており、2つのプログラムを比べてより土台（ハードウェア）に近い機能を持つ方をプラットフォーム側のプログラムと呼んでいます。
たとえば、WindowsにMicrosoft Officeをインストールした状況を考えると、
アプリケーションであるOfficeから見て、OSであるWindowsはよりプラットフォーム側のプログラムです。
そしてMinecraftとJava環境(JRE)を比べれば後者がよりプラットフォーム寄りと言えます。
インタフェースについて
Interfaceとは、
- 「inter-」 ～の間の。
- 「-face」 顔。ここでは窓口のような意味です。
つまりインタフェースとは、2つのモノがやり取りするときの窓口を意味します。
ただし、『窓口』といっても、銀行や役所にある具体的な窓口をイメージしてはいけません。
むしろ「Jリーグ入団への窓口」「絵画の世界への窓口」のような抽象的イメージを持った『窓口』です。
ソフトウェアインタフェースについて
ソフトウェアどうしが何らかのやり取りをするとき、そのやり取りの窓口をソフトウェアインタフェースと呼びます。当然ながらこの『窓口』は実体を持つようなものではありません。抽象的な概念です。
もう少し詳しく説明しましょう。
互いに相手のことをよく知らないソフトウェアどうしが、スムーズにやり取りをするために必要なものは何でしょうか。
それはルールです。
- たとえば、機能を利用するためにはどの窓口を使えばいいかのような根本的なルールを知らなくては話になりません。
- またあるいは、「最初にHELLOと挨拶してから用件を告げる。返事が返ってきたらお礼の言葉を言う。やり取りが終わったらBYEと言う」のような、通信するときの規約（これをプロトコルと言います）があると安全かもしれません。プロトコルを最初にしっかりと決めておけば、後はそのプロトコルを守り続ける限り、誤解や無駄なやりとりは生じません。
このように、ソフトウェア同士が通信するときに必要なルールをしっかりと決めておくことがやり取りの窓口となるわけです。
よってソフトウェアインタフェースとは「ソフトウェア同士がどのように通信すべきかを明確に決めたもの（＝仕様）」を意味します。
そしてAPIは、ソフトウェアインタフェースの代表例です。
APIを再び考える
以上の知識を押さえた上で、APIの定義をもう一度挙げます。
API（Application Programming Interface）とは、「プラットフォーム側のプログラムがその機能をアプリケーションプログラムから利用できるように公開したインタフェース」です。
どうでしょう、だいぶ理解が進んだでしょうか。
え？ まだぴんと来ない？ もうしょうがないなぁ。つまり、ぶっちゃけると。
- プログラマ「プラットフォーム側にあるプログラムよおらに力を貸してくれ」
- プラット側「おｋ。利用するためのルールまとめておいたからこれ見てから使ってくれ」
- この利用するためのルール（＝利用するための仕様）が、APIです。
APIを実装と切り離すこと
ここで注意したいのは、良いAPIとは何かということです。
良いの観点は複数ありますが、利用者が使いやすいAPIであるかどうかという観点は特に重要でしょう。
たとえば利用者にとって、使うための手間や前提条件は少ない方が使いやすいです。
インタフェースの向こう側の事情を知らなくても、どのような状況であっても最小限の手続きで利用できる。たとえば「○という関数はXXXXXという機能を持っており、△という引数で実行すれば、□という返し値が返される」のような、機能を利用するための必要最小限の情報だけで構成されているAPIは良いAPIと言えます。
そのためにはAPIを適度に抽象化し、実装と切り離してしまうことが有効です。
またAPIを実装から切り離すことで別の意味でも利点があります。
たとえば、プログラムのソースコードやアルゴリズムを公開したくない場合でも、抽象化したAPIによって、その機能だけを外部に提供することができます。
そして抽象化したAPIを公開して広く周知させることで、APIの実装を他者にゆだねることもできます。
たとえば、APIを実装する人（会社・組織）や方法（言語・アルゴリズム）や場所（プラットホーム）によって、同じAPIでも様々な実装が生まれることがあります。Windows APIなどは典型的ですね。
APIを解説したページ
世の中には様々なAPIが存在しており、それらAPIはたいていインターネット上で詳しく解説されています。
CC非公式Wikiや公式WikiのAPI解説ページもその一つで、CCプログラミング中には必ず開いている、まさにバイブルと言っても過言でない重要なページです。
まとめ： それではTurtle APIって何だろう
CCコンピュータは「Craft OS」、タートルは「Turtle OS」というOSが動いている。
そしてそれぞれのOSが、僕たちCCプログラマに対して様々な機能を提供してくれる。
ComputerCraftはこういう想定で作られています。（内部的にはこれらOSの実体は仮想的なものですが）。
つまり「Turtle OS」から提供される「Turtle API」によって、僕たちCCプログラマはタートルを操作するという機能を利用できるのです。
これまでの僕たちはOSから提供される機能を利用する側でした。
今度は、提供する側、APIを作る側に回ってみましょう。
便利なAPIを作ることができれば、今後のCCプログラミングがさらに楽しくなるはずです。
それでは次回から、APIを作っていきましょう。
補足
気持ち悪いからやめて
英語で「API specifications」を「API仕様」と訳すのはやめてくださいおねがいします。
訳すならせめて「API仕様書」でしょう。
「仕様」と「仕様書」は違う。
だって「設計」と「設計図」は違うものでしょ。それと同じですよ。
「HTTPプロトコル」並に気持ち悪いです。
「API 仕様」でググったらダメだぞ。絶対ニダ！
Web API について
Web APIって提言したの誰だっけ。頭いいよね。ネーミングセンスうらやましい。
つまり、「ネットにつながったコンピュータの全ては、インターネットをプラットフォームにできるんだ」ということだよね。夢があるわ。
インターネットの向こうにある様々なサービス（中ではプログラムが動いている）が提供するAPIを利用すれば、それらサービスを利用した様々なプログラムが組める。
すごい世の中になったものです。
