はじめに
Web APIが何なのか、よく分からなかったので調べました。
読み終わる頃にはWeb APIについてなんとなくイメージが掴めていると思います。
目次
1. APIの定義
2. Web APIの成り立ち
3. Web APIの一例(openBD)
4. Web APIとRESTの関係
5. Web APIとJSON
この記事で説明すること
・Web APIの歴史
・Web APIの実例紹介
この記事で説明しない(できない)こと
・Web API開発方法
・TCP/IP, REST, JSONの具体的な内容
1. APIの定義
APIについてWikipediaでは以下のように定義されています。
アプリケーションプログラミングインタフェース（API、英: Application Programming Interface）とは、広義ではソフトウェアコンポーネント同士が互いに情報をやりとりするのに使用するインタフェースの仕様である。
APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIXのような国際標準規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語の標準ライブラリ（例えば、C++のStandard Template LibraryやJava APIなど）がある。
商業的に使われる狭義では、各種システムやサービス（ハードウェア、OS、ミドルウェアおよびWebサービス等）を利用するアプリケーションソフトウェア (Application) を開発・プログラミング (Programming) するためのインタフェース (Interface) である。こちらの意味では、システムやサービスから直接提供されないもの、例えば言語の標準ライブラリは含まない。
APIはとても広義な概念なので、様々なものがあります。
例えば一言にカレーといっても、カツカレーやスープカレー、マッサマンカレーなど様々な種類があるように、APIにも種類があります。
今回取り扱うWeb APIは、APIの中でもHTTP/HTTPS通信を使用して利用するAPIを指します。
Web APIはAPI、公開API、Webサービスと呼ばれたりします。
Web APIの中にも、大きく２種類あります。
・企業内部などで使用する内部API
・Webサービスとして全世界に提供する公開API
公開APIの代表例として、AmazonやGoogle, Twitter, Facebookが挙げられます。
以降は公開APIについて取り扱います。
2. Web APIの成り立ち
Web APIが普及した歴史をかなりざっくり追います。
インターネットが生まれ、複数のコンピュータを接続した分散システムが構築されました。
Webとは、何(HTML)がどこ(URI)にあって、どうやってアクセス(HTTP)するかを決めて、結びつけたシステムです。
Webの仕組みによって世界中の不特定多数のユーザーが情報にアクセス、発信できるようになりました。
Webで使うAPIも、分散型で、多くのユーザーが使用します。
なので、APIもWebが上手くいった仕組みに乗っ取って、URIを指定してHTTP/HTTPS通信でアクセスできると楽だよねとなりました。
(本当にざっくりですみません...。
より詳しく知りたい方はこちらの文献を参考にしてください)
参考 : APIとは。歴史を振り返る | NTT Communications Developer Portal
3. Web APIの一例(openBD)
以下はopenBDというWeb APIの使用例です。
ISBNという10,13桁のコードに対応した、一意の書籍情報を取得できます。
書籍Webを支える技術に関する情報をJSON形式で得ることができました。
Web APIから受け取る情報はJSON形式であることが多いです。
上記のようだと、人間には分かりづらいですね。
以下は見やすく整形したものになります。
書籍のあらゆる情報を提供してくれていることが分かります。
実際にWeb APIとして使用する際は、取得した情報を加工して、新しいサービスに利用します。
4. Web APIとRESTの関係
なぜJSON形式で情報を受け渡すのでしょうか？
それにはRESTという概念が深く関わっています。
先にWeb APIとRESTの関係について理解します。
Webが急速に普及するにつれて、2000年頃にある問題が表面化しました。
それはHTTPなどプロトコルのガイドライン策定が追いつかなかったことです。
そして各々が独自の規格を提案して実装するようになりました。
そこでWebをプログラムから利用する仕組み(Web API)を定義しようと台頭した主な２つが、
SOAPとRESTです。
SOAP陣営は、HTTPをトランスポート層として扱い、SOAPをアプリケーション層の新たなプロトコルにしようと提案しました。
ここで、簡単にTCP/IPプロトコルについて説明します。
TCP/IPとは、現在用いられているインターネットの通信プロトコルの総称です。
役割ごとに4つの階層に分かれています。
| 階層 | プロトコル |
|---|---|
| アプリケーション層 | HTTP, SSH, FTP, etc |
| トランスポート層 | TCP, UDP, etc |
| インターネット層 | IP, ARP, etc |
| ネットワークインターフェース層 | Ethernet, PPP, etc |
各層にはそれぞれ固有の役割があります。
アプリケーション層は、アプリケーション同士の通信プロトコルを取り決める、
トランスポート層はデータの転送を制御する、などです。
話を戻すと、
SOAP陣営は、既存の通信プロトコルに対して新たな概念を並列に1つ増やしました。
一方でREST(Representational State Transfer)陣営は、
HTTPはハイパーテキストだけでなく、リソースの状態の表現を運んでいると主張しました。
つまり、既存のプロトコルの上位概念としてRESTを新たに定義しました。
これは、当時のWebが上手く行っている仕組みをRESTと定義したと言い換えることができます。
Web APIを開発する際は、
Webが上手く回っている仕組みをそのままAPIにも取り入れたら、Web全体がスマートに運用できてユーザーも開発者もwin-winだよね
という感じです。
結果的にマッシュアップ(様々なWeb APIが提供する情報を組み合わせて、一つのサービスとして提供する)が盛んになってきた当時、
HTTPとURIで情報を取得する手軽さを持つRESTなAPIが好まれて主流になりました。
(RESTが具体的に何なのかは解説しません。すみません分かりません。)
参考: REST と SOAP の違い
ただし、提供したいサービスによってRESTとは別のコンセプトでサービスを作ることもあります。
最も大切なことは価値のあるサービスを提供することで、RESTなAPIを提供することではありません。
実際に、RESTとは別のコンセプトであるPeer to PeerやGraphQLでも素晴らしいサービスが提供されています。
Peer to Peerの例、Skype, Line
GraphQLの例、Facebook, GitHub
5. Web APIとJSON
RESTであるWeb APIが推奨される傾向が強い理由は分かりました。
では、なぜJSON形式で情報を受け渡すのでしょうか？
それはWeb APIのフォーマットとして以下の2点が重要であり、
・送受信コストが低い
・JavaScriptで扱いやすい
XMLなどと比較して、JSONは上記の2点で優位性を持っていました。
そのためJSONが好んで使われるようになり、デファクトスタンダードになりました。
前述したJSON形式で情報を受け取るWeb API(openBD)の事例を見てみましょう。
URLに注目してください。
isbn=4774142042で一意の書籍をURIで指定しています。
さらにWebブラウザからHTTPS通信することで、情報をJSON形式で取得しています。
仮にHTML形式で取得していたらどうでしょうか。
マークアップしてある方が、人間からすると見やすいです。
しかし、Web APIを利用する理由は、あくまで情報を取得してマッシュアップするためです。
つまり視覚的な見やすさではなく、コンパクトにまとまった情報が欲しいのです。
また、マークアップしてしまうと表現が冗長になり、通信帯域を圧迫してしまうことにも繋がります。
従って、コンパクトにまとまった情報を取得できるJSON形式が、Web APIのフォーマットとして使われる傾向が強まりました。
6. まとめ
Web APIとは、コンパクトにまとまった情報を取得するものです。
そして、Webが上手くいった仕組みをTCP/IPの上位概念として定義したのがRESTで、
RESTのコンセプトを取り入れたWeb APIが広く受け入れられました。
現在は、RESTとは別のコンセプト(Peer to PeerやGraphQL)を元に開発されて普及しているWeb APIも多く存在します。
大切なことは価値のあるサービスであるかどうかで、RESTであるかは必須条件ではありません。
ただしWeb及びWeb APIが発展した歴史の中に、RESTの思想が組み込まれているのは事実としてあります。
以下感想
上記を押さえて置くことが開発の際に大切になるのかなと思います。
openBDの例で、
URIを指定してHTTPS通信しただけで、手軽に情報を取得できて、
RESTなAPIの良さを体感できました。
個人的な一番の収穫は、RESTが一番いいのかなと思っていたけど、そう単純な話ではないんだなーと知ったこと。
実際の実装を通して良いものを生み出せるようになりたい。
7. 参考資料
API とは | Red Hat
5分で分かるWebAPI | NTT Communications Developer Portal