こんにちは、Juntechです。
今回は「API」について解説してみようと思います。
APIについては過去の記事でもかなりざっくり紹介しました。
が、今後いろんな記事でこの「API」という言葉を当たり前のように使っていくので、
APIってなんだっけ?となった時のために、
API解説の記事を作っておくことにしました。
この記事を読めば、皆さんも明日からドヤ顔でAPIを語れます。
APIとは
APIとは、Application Programming Interface(アプリケーションプログラミングインタフェース)
の略です。
データのやりとりに使うもの
硬い言葉で言うと、
アプリケーションがサーバーサイドに実装されたサービスを利用するために使用される、データ送受信手続きのことです。
皆さんスマホで色んなアプリ使ってますよね。
Google Chromeとか。iTunesとか。
こいつらって、インターネットを使って、
いろんなサイトを検索したり、曲を引っ張ってきたりしてますよね。
これってなんでやってるのかというと、
各スマホに情報を全て保存しておくとデータ多すぎてやばいことになるからですよね。
だからスマホには最低限の情報だけ持っていて、
膨大なWebサイトや曲は、Googleやらアップルやらの、コンピューターの中に置いてあるんです。
これをスマホで引っ張ってくるために使うのが、APIです。
一般的にはWebAPIとして表現される
APIそのもので言うと、必ずしもWebサービスで使うものに限りません。
限られたコンピュータ同士で限られた経路でデータをやりとりするAPIも存在します。
が、一般的に「API」というと、
皆さんがGoogle ChromeやSafariなどでサイトにアクセスする時に使っている「HTTP/HTTPS」で通信する、
「WebAPI」が主流です。
システム開発の現場で「APIで実装しよう」とか「ここはAPIでやりとりしてるよ」とか言うときも、
99%の確率でWebAPIのことを指していると思って大丈夫です。
なので今度からAPIについて詳しく知りたいと思ったら、
「API」でなく、「WebAPI」でググってください。
より分かりやすい解説が増えると思います。
このブログでも、WebAPI=APIとして記事を書いていきます。
たくさんのAPIが公開されている
様々なWEBサービス・企業がAPIを公開しています。
少し前だと、楽天がAPIのマーケットプレイスを開始して話題になりました。
https://api.rakuten.net/
私も登録しています。だいぶ重いですが...。
AmazonやYahooなどでもネットショップ用のAPIを公開していて、
出品者はAPIを使って商品登録や注文取得などができるようになっています。
APIの使い方を知っているだけで、
自分自身は情報を持っていなくても、
様々なアプリ・サービスを生み出すことができるんです!
試しに使ってみよう
ついでに簡単なAPIを1つ触ってみましょう。
実装に興味ない人はこのセクションは飛ばしていただいて大丈夫です。
Macユーザーはターミナルから使えます。
Windowsユーザーはちょっと手間がかかりますが、
curlをインストールするか、
git for windowsをインストールして付属してくるGit Bashを使うのがおすすめです。
が、試すだけであればAPIクライアントを使うのが手っ取り早いです。
無料で使えるAPIクライアント
APIクライアントとは、
プログラムを書かなくてもAPIを叩ける(=実行できる)ソフトです。
私も開発する際には、まずAPIクライアントで試してみてから、
プログラムに組み込んでいます。
おすすめなのは2つです。
Talend API Tester
Chrome拡張機能で使えるAPIクライアントです。
https://chrome.google.com/webstore/detail/talend-api-tester-free-ed/aejoelaoggembcahagimdiliamlcdmfm?hl=ja
以前は「Restlet Client」という名前で、最近名前が変わったみたいです。
ダウンロード/インストールの手間がないのですぐに使えます。
Postman
ダウンロードして使えるAPIクライアントアプリです。
https://www.postman.com/
NewManというNodeJS用のライブラリがあり、
Postmanで作った設定情報をファイル化することで、
簡単にプログラムに組み込むことが出来たりします。
早速やってみよう!
私は普段Postmanを使っているのですが、
今回は簡単に導入できるTalend API Testerを使ってみましょう。
まずはコチラから、Chromeに追加しましょう。
追加後に紫のアイコンをクリックすると、こちらの画面に飛びます。
青いボタンを押して始めましょう!
http://geoapi.heartrails.com/api.html
無料で使える、地理情報取得APIです。
このAPIを使って、日本の各地方と、都道府県を取得してみましょう。
今https://
と表示されている部分を、下記に変えてみましょう。
http://geoapi.heartrails.com/api/json?method=getAreas
これで、地方が取得できます。
できたら、Sendを押してみましょう。
「200 OK」と表示されていますが、
これは「HTTPステータス」というステータスの1つで、
200は「正常に情報が取得できたよ」という意味のコードです。
そして取得された情報が、「BODY」の部分です。
{
"response":{
"area":[
"北海道",
"東北",
"関東",
"中部",
"近畿",
"中国",
"四国",
"九州"
]
}
}
これは「JSON」という書式で、ポピュラーなデータ書式の1つです。
他には「XML」という書式が有名です。
これで地方の取得ができました。
今度はこれを使って、都道府県を取得してみましょう。
http://...
の部分を、下記に変えます。
http://geoapi.heartrails.com/api/json?method=getPrefectures&area=九州
これで、九州地方の都道府県を取得することができます。
実行してみましょう。
返ってきたBODYがこちら。
{
"response":{
"prefecture":[
"福岡県",
"佐賀県",
"長崎県",
"熊本県",
"大分県",
"宮崎県",
"鹿児島県",
"沖縄県"
]
}
}
無事九州の都道府県が取得できました!
沖縄地方がないと思ったら、九州にいたんですね。
ちなみに&area=九州
を外せば、47都道府県が取得できます。
便利ですね!
よくアプリで住んでいる都道府県を選択する箇所があったりしますが、
これらの選択肢も、大体はAPIで取得していたりします。
こうやって、
プログラムに直接ベタ書きするのでなくAPI経由で取得することで、
プログラムのメンテナンスが不要になるのも、
APIの利点の1つです。
ちなみにRESTも解説
最近だとAPI開発界隈でよく出てくるのが「REST」です。
これは一言でいうと、APIサービスの設計思想および実装方式のことなんですが、
4つの基本原則がうたわれています。
REST 4つの基本原則
- ステートレスなクライアント/サーバプロトコル
- すべての情報 (リソース) に適用できる「よく定義された操作」のセット
- リソースを一意に識別する「汎用的な構文」
- アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
よくわからんですね。
もう少し簡単に言うとこうなります。
- URLは操作でなく、扱うリソースを意味する
- 情報のやりとりにおいて前後の情報を持たない
URLは操作でなく、扱うリソースを意味する
URLっていうのはさっき使ったhttp://...
みたいなやつですね。
リソースというのは、ユーザ情報とか、商品情報とか、つまり情報資源のことです。
先ほど使ったURLだと、getPrefectures
やgetAreas
といった、
地方や都道府県の情報を「取得」したいよ〜と言った操作情報を持っています。
これはRESTfull(RESTな)APIとはいえません。
ではRESTfullAPIはどうなっているかというと、例えばこんな感じになります。
http://geoapi.heartrails.com/api/json/prefectures?area=九州
これだと、九州地方の都道府県が何なの?て感じですよね。
ここで情報を取得したいのか、登録したいのか、削除したいのか、といった操作を持たせるのが、メソッドです。
メソッドにはGET
やPOST
、PUT
、DELETE
などがあります。
先ほど使ったAPI Testerにもありましたよね。
これです。
RESTfullAPI(REST API)では、このメソッドをURLと一緒に渡すことで、
初めて何をしたいのかということが明らかになる作りとなっています。
情報のやりとりにおいて前後の情報を持たない
REST APIでは、APIを実行する前後の情報を一切考慮しない作りになっています。
例えば、予約サイトにログインしてから予約を行い、予約内容をもらう、という一連の作業をするとしましょう。
RESTでなければ、
- ログインする
- 予約する
- 予約内容をもらう
という簡単な作業で済みます。
が、これをREST APIでやるとこうなります。
- ログインする
- ログインして予約する
- ログインして予約番号を伝えて予約内容をもらう
RESTは前後の情報を持たないので、
APIを使う側が、常にフルで情報を提供する必要があるのです。
これを「ステートレス」といいます。
反対に前後の情報を持っているものを「ステートフル」と言います。
ステートレスとステートフル
ステートフルな場合には、
最初のログインのタイミングから、
ずっとユーザ情報を保持し続ける必要があります。
(一定のタイミングで捨てるので、永久に持っているわけでありません。)
ステートレスはクライアントからすると不便に見えますが、
サービス側からすれば何万ユーザもの膨大な情報を保持しておく必要がありません。
その分サービスを拡大させやすく、
このREST思想は今のWEB時代にはとても有益なものとなっています。
だからこそ、REST設計をできるエンジニアは、
スタートアップやスモールスタートしたいサービス事業において価値のある存在なのです。
今日はここまで。
APIは自動化に欠かせない存在なので、
これからも幾度となく使う機会が訪れます。
自動化に興味がある人は、
ぜひ1ヶ月後、3ヶ月後とかにもう一度読み返してみてください!