Web APIとは何か理解する

はじめに
-
Web APIが何なのか、よく分からなかったので調べました。

読み終わる頃にはWeb APIについてなんとなくイメージが掴めていると思います。


目次
-
[1. APIの定義](#1-apiの定義)
[2. Web APIの成り立ち](#2-web-apiの成り立ち)
[3. Web APIの一例(openBD)](#3-web-apiの一例openbd)
[4. Web APIとRESTの関係](#4-web-apiとrestの関係)
[5. Web APIとJSON](#5-web-apiとjson)



この記事で説明すること
・Web APIの歴史
・Web APIの実例紹介

この記事で説明しない(できない)こと
・Web API開発方法
・TCP/IP, REST, JSONの具体的な内容



## 1. APIの定義


APIについて[Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9)では以下のように定義されています。
>アプリケーションプログラミングインタフェース（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](https://developer.ntt.com/ja/blog/556bdab4-1583-4763-839b-19ba892252cf) 

## 3. Web APIの一例(openBD)

以下は[openBD](https://openbd.jp/)というWeb APIの使用例です。
[ISBN](https://isbn.jpo.or.jp/)という10,13桁のコードに対応した、一意の書籍情報を取得できます。
書籍[Webを支える技術](https://www.amazon.co.jp/Web%E3%82%92%E6%94%AF%E3%81%88%E3%82%8B%E6%8A%80%E8%A1%93-HTTP%EF%BC%8CURI%EF%BC%8CHTML%EF%BC%8C%E3%81%9D%E3%81%97%E3%81%A6REST-WEB-PRESS-plus-ebook/dp/B07JK7FZH2/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=)に関する情報をJSON形式で得ることができました。
Web APIから受け取る情報はJSON形式であることが多いです。

<img width="100%" alt="demo_openbd_browser" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/516687/cc47a0ff-0880-ff00-615f-ded5565ae8d0.png">

上記のようだと、人間には分かりづらいですね。
以下は見やすく整形したものになります。

<img width="100%" alt="demo_openbd_terminal" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/516687/fa2fb0f0-1ddf-9bd7-68ea-14d85168ac9f.png">

書籍のあらゆる情報を提供してくれていることが分かります。
実際に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 の違い](https://www.redhat.com/ja/topics/integration/whats-the-difference-between-soap-rest) 

ただし、提供したいサービスによってRESTとは別のコンセプトでサービスを作ることもあります。

**最も大切なことは価値のあるサービスを提供することで、RESTなAPIを提供すること**ではありません。

実際に、RESTとは別のコンセプトである[Peer to Peer](https://ja.wikipedia.org/wiki/Peer_to_Peer)や[GraphQL](https://ja.wikipedia.org/wiki/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)の事例を見てみましょう。

<img width="100%" alt="demo_openbd_browser_url" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/516687/26d8e698-3fd8-349d-9b8b-42f7e603f591.png">

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](https://www.redhat.com/ja/topics/api/what-are-application-programming-interfaces) 
[5分で分かるWebAPI | NTT Communications Developer Portal](https://developer.ntt.com/ja/blog/5%E5%88%86%E3%81%A7%E5%88%86%E3%81%8B%E3%82%8BWebAPI)