クモのようにコツコツと

フロントエンドエンジニア イイダリョウの技術ブログ。略称「クモコツ」

トップ > 開発環境 > REST APIとは何かを調べまくったらようやくイメージができてきたのでまとめた

REST APIとは何かを調べまくったらようやくイメージができてきたのでまとめた

開発環境 JS DB REST API

数年前からキーワードとしては知っていた「REST API」。それが何かはいまいち理解できていなかった。調べまくったところフロントエンドとバックエンドの分業の流れがようやく理解できました。「API」と「JSON」への理解も重要でした。それではいきましょう！

【目次】

※Web開発環境についてまとめ qiita.com

REST APIについてフワッとしていた

フロントエンドとバックエンドを連携する上で「REST API」を使うらしいというところまではわかっていた。しかしそれがどんなものなのかは調べてもなかなかイメージできなかった。

既にREST APIがわかっている人、使っている人、作っている人たちはよくこんな言い方をしている。

  • RESTにする
  • APIを叩く
  • JSONを返す

ほえ？RESTにする？何を？どうやって？APIを叩く？どうやって？JSONを返す？あげたっけ？

よくわからなかった。

APIとは

そもそもAPIとは何か

RESTの前の話としてAPIとは何なのか。

自分がフロントエンドで馴染み深いのはWebGL API、Web Audio APIとかだ。これらを使う時に「APIを叩く」という感覚はない。どうもバックエンドエンジニアの方がいうAPIとは概念が異なる気がする。

つまり、だ。API自体がよくわかっていない。雰囲気だけで使っている。APIとはいったい何なのか？

APIとは、あるコンピュータプログラム（ソフトウェア）の機能や管理するデータなどを、外部の他のプログラムから呼び出して利用するための手順やデータ形式などを定めた規約のこと。

※参考：API（アプリケーションプログラミングインターフェース）とは - IT用語辞典 e-Words

ほえ？APIとは規約なのか？ではAPIを叩くとは？使うとは？作るとは？どういうことか。

ここで着目すべきはAPIという略称の元の単語だった。APIとは「Application Programming Interface 」の略。

アプリケーション（A）はわかる。アプリやソフトのことだよね。プログラミング（P）もわかるコンピュータに命令する言語。

3つ目のインターフェース（I）、ここに着目。これまであまり意識してなかったがなんとAPIとはインターフェースだったのか！

インターフェース＝接点

インターフェースとは、接点、境界面、接触面、接合面、仲立ち、橋渡しなどの意味を持つ英単語。IT関連では、二つのものが接続・接触する箇所や、両者の間で情報や信号などをやりとりするための手順や規約を定めたものを意味する。

※参考：インターフェース（I/F）とは - IT用語辞典 e-Words

これはわかる。我々は生活の中でインターフェイスに触れている。例えば「UI（User Interface）」はユーザーとコンピュータの接点。

そして「CUI（Character User Interface）」は黒い画面（ターミナル）上の文字だけでユーザーとコンピュータをつなげる。

一方「GUI（Graphical User Interface）」はマウスを使ってウィンドウなどの視覚的な形でユーザーとコンピュータをつなげる。

※参考：今さら聞けないユーザーインターフェイス (UI) の基本

で、APIは「アプリケーション」と「プログラム」を繋げているというわけか！！

Web APIとは何か

APIについて調べるとだいたいが「Web API」の解説になる。しかし実際にはAPI=Web APIというわけではないようだ。

例えばこちらの記事では銀行の入金APIについての解説がある。ATMを使ってお金を入金するときはこのAPIが使われる。

具体的なAPI利用の例として、銀行口座に対して入金する場合を考える。API提供者が入金サービスをAPI（以下、入金API）で提供しており、そのサービスには

  • 銀行口座へのアクセスを許可する認可機能
  • 現在残高の確認機能
  • 入金額と現在残高を合算する機能
  • 合算後の残高を表示する機能

が存在する。API利用者は入金APIに対して必要なパラメーターを与えるだけで、上記の機能全てが実現し、煩雑な機能の設計や実装といった作業から解放される。

Web APIはそうしたいろいろなAPIの中の一種というわけか。

Web APIとは、先に述べたAPI提供者とAPI利用者とのやりとりをHTTP／HTTPSベースで実現するAPIだ。

※参考：APIとは何か？ Web APIとの違い、利用者のタスクを解説 (1/2)：基礎から分かるAPI管理【第2回】 - TechTargetジャパン システム開発

こちらの解説もわかりやすかった。

あなたの家で機器を使いたい時には、電源コードのプラグをコンセントに差し込めば事足ります。電源に直接結線したりしないでしょう — そんなのは非効率ですし、あなたが電気工事士でなければ、やってみるには難しいし危険です。

このコンセントに当たる部分がAPIということね。

そしてWeb APIには「ブラウザAPI」と「サードパーティAPI」があるらしい。

ブラウザ API は Web ブラウザに組込まれていて、ブラウザやコンピュータの環境の情報を取得し、これを使って役に立つややこしい事を行えるようにするものです。

サードパーティ API はデフォルトではブラウザに組込まれておらず、普通はコードと情報を Web のどこから読み込まねばなりません。

※参考：Web API の紹介 - ウェブ開発を学ぶ | MDN

自分がこれまでフロントエンドで利用してきたWebGL APIなどはブラウザに最初から組み込まれている「ブラウザAPI」だったんだ！

そしてWeb上から読み込んで利用するTwitter APIなどは「サードパーティ API 」ということか。

APIを「叩く」とは？

で、冒頭に書いた「APIを叩く」というニュアンスは、「サードパーティAPI」を理解するとイメージがしやすい。

APIを叩くというのは、APIを実行することのスラングです。リクエストを叩いたら、レスポンスが返ってくるためと思われます。

なるほどなるほど。スラングだったのね。

「エラーを吐く」「バッチを回す」（別プログラムを）「キックする」
なんかが、私の周りのテクニカルの現場ではよくあります。

あー確かによく聞くフレーズw

※参考：REST APIを「叩く」って何？ツール使ったら初心者でも簡単だった | kintone hive online

ブラウザAPIはもともとブラウザに組み込まれている機能のため、組み込み関数を使うのと似た感覚だった。

それに対してサードパーティAPIはネットワーク越しに「リクエストを叩いたら、レスポンスが返ってくる」ために「叩く」というイメージになったわけだ。

RESTとは

REST APIのRESTとは何か

で、ようやくRESTです。RESTとは何か。Restという単語は「残り」という意味になるが、 RESTは全部大文字で略語なんですな。

RESTは「REpresentational State Transfer」の略。これをGoogle先生で翻訳すると「代表的な国家移転」となった。

f:id:idr_zz:20200204052901j:plain

国家を移転するとはまたずいぶん大それた話w しかしこのStateはおそらく国家という意味ではない。

RESTの原則

  • アドレス可能性(Addressability)
    提供する情報がURIを通して表現できること。全ての情報はURIで表現される一意なアドレスを持っていること。
  • ステートレス性(Stateless)
    HTTPをベースにしたステートレスなクライアント/サーバプロトコルであること。セッション等の状態管理はせず、やり取りされる情報はそれ自体で完結して解釈できること。
  • 接続性(Connectability)
    情報の内部に、別の情報や(その情報の別の)状態へのリンクを含めることができること。
  • 統一インターフェース(Uniform Interface)
    情報の操作(取得、作成、更新、削除)は全てHTTPメソッド(GET、POST、PUT、DELETE)を利用すること。

※参考：RESTful APIとは何なのか - Qiita

ふむふむ、RESTのSのStateは国家ではなくこの「ステートレス」から来ているんだな。

ちなみにこの4原則が全て揃った状態を「RESTful」というが「REST」とほぼ同義と考えて良さそうだ。

ステートレスとは何か

ステートレスについても調べる。まず「ステート」とは何か。

ITの分野では「状態」の意味で用いられることが多い。

ITにおける「ステート」は国家ではなく「状態」を意味するようだ。

※参考：ステートとは - IT用語辞典 e-Words

で、ステートには「ステートフル」と「ステートレス」の2種類がある。

ステートフルとは、状況によって、あるリクエストをしたら、レスポンス（対応や反応、応答内容等）が変わるもの。

ステートレスとは、状況によらず、あるリクエストをしたら、必ず同じ結果になるもの。特に、それまでのリクエスト・レスポンスのことは一切考えず、今来たリクエストを額面通りに受け取って回答するもの

※参考：【初心者向け】ステートフル(Stateful)とステートレス(Stateless)の違い,IPv6やAWSでの考え方│SEの道標

そして、普段慣れ親しんでいるHTTP通信は「ステートレス」というわけだ。

ステートレスについてはこちらの記事が分かりやすかった。

（ステートレスの例）：
客: こんにちは
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとジンジャーエールでお願いします
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします
店員: 以上でよろしいですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上
店員: かしこまりました

ハンバーガー店で、メニューの指定をするたびにいちいち最初から全部の品名を伝えるお客さん。

一見うざったそうだがw これによって店側にとっては注文の途中で店員さんを入れ替えてもメニューが正確に伝わるわけだ。

  • リクエストには、処理に必要な情報を含む
    ステートフルとは異なり、自己完結型である
  • サーバ資源をすぐに開放できるという利点があり、利用者や負荷におういて性能や機能を向上させられる
  • アプリケーションの状態を覚える必要がないため、サーバ側のシステムは単純になる

フロントとバックを分けるからこそのテクなんだろうなと。

※参考：ステートレスとは - Qiita

RESTはアーキテクチャだった

アーキテクチャスタイル「REST」とは何か

という記事があって、このタイトルによってRESTはアーキテクチャだとわかる。

※参考：アーキテクチャスタイル「REST」とは何か | Think IT（シンクイット）

では、アーキテクチャとは何か。

「アーキテクチャ」は英語の「architecture」のことで、大きく分けて３つの意味に分かれます。

1つは学問としての「建築学」で、総合建築を学ぶ大学での専門分野のこと。2つ目は建築そのものを指し、「建築構造」「建築様式」「建築術」などを意味しています。そして３つ目が建築という軸の意味から派生して生まれた「ソフトウェア、またはハードウェアの基本的な設計概念」という意味での「アーキテクチャ」です。

※参考：https://biz.trans-suite.jp/8540

もともとは建築そのものを意味したが、そこからIT分野での「設計概念」という意味に派生したと。なるほど。

で、RESTはITの設計概念の中の一つということか。

JSONとDB

XMLとJSONの違い

RESTでやりとりできる情報として「XML」と「JSON」がある。また、RESTとよく比較される仕様で「SOAP」というものもあり、こちらはXMLのみでやりとりされる。

※参考：今さら聞けないWebAPIの実装方式RESTとSOAPの違い - Qiita

XMLは「Extensible Markup Language」の略でHTMLのようにタグで囲うマークアップ言語。

<?xml version="1.0" encoding="Shift_JIS" ?>
<はっぴいえんど>
    <作品>アルバム</作品>
    <アルバム>
        <タイトル>はっぴいえんど</タイトル>
        <発売年>1970</文>
    </アルバム>
    <アルバム>
        <タイトル>風街ろまん</タイトル>
        <発売年>1971</文>
    </アルバム>
    <アルバム>
        <タイトル>Happy End</タイトル>
        <発売年>1973</文>
    </アルバム>
</はっぴいえんど>

※参考：XMLの基礎

一方JSONは「JavaScript Object Notation」の略でJSのオブジェクト（連想配列）と似た形式。

{"はっぴいえんど": {
    "アルバム": {
       "タイトル": "はっぴいえんど",
       "発売年": "1970"
        }
    },
    "アルバム": {
       "タイトル": "風街ろまん",
       "発売年": "1971"
        }
    },
    "アルバム": {
       "タイトル": "Happy End",
       "発売年": "1973"
        }
    }
}

JSONの方がシンプル。そしてJSのオブジェクトにも変換がしやすいため、最近はこちらが多く使われている。

  • JSON→JSの変換はJSON.parse()で行う
  • JS→JSONの変換はJSON.stringify()で行う

※参考：【JavaScript】JSONのparseとstringifyメソッドの使い方 - TASK NOTES

XML、JSONは共にデータ形式であり、エクセルからエクスポートされるCSVもその一つ。

※参考：【何が違う？】データ形式(CSV, XML, JSON)の特徴を知ろう | CodeShip blog

なお、非同期通信「Ajax」は「Asynchronous JavaScript + XML」の略で生まれた当初はXMLが使われた。しかし最近はJSONが主流になってきている。（そしたらAjajエイジャッジかw）

※参考：初心者目線でAjaxの説明 - Qiita

（2020/02/19追記）
自分には疎い世界だったが2010年頃からすでにXMLよりJSONが主流になってきたようだ。XMLを作った人たちによればXMLはWebのデータのやり取りだけのために作ったわけではないと。そのためシンプルなJSONの方がマッチしたわけだ。

※参考：JSONに押されるXMLの存在 － Publickey

データベース（DB）はテーブル形（RDB）が主流

ところでデータ（デジタル情報）の集まりをデータベース（DB）という。

「データベース」とは、ある特定の条件に当てはまる「データ」を複数集めて、後で使いやすい形に整理した情報のかたまりのこと

※参考：そもそもデータベースとは？基礎から分かるデータベース入門 | サービス | プロエンジニア

データベース（DB）はエクセルのように行と列があるテーブル（表）形式が主流。

※参考： https://academy.gmocloud.com/know/20160425/2259

テーブル形のDBは「RDB」と言われる。「Relational Database」の略で関係データベースとも言われる。

※参考：RDB（リレーショナルデータベース）とは | 関係データベースとNoSQLとの違い - 経営企画・マーケティング | ボクシルマガジン

RDBのデータを操作するにはSQLが使われる。

※参考：リレーショナルデータベースとSQL - Qiita

では、JSON形式のデータはどうしたらいい？

JSON＝NoSQL、というわけではない！

RDBはSQL、ではJSONはNoSQL？調べるとそんな単純な話でもないみたい。

「Not Only SQL」の略であり、「SQLだけでなく、新しいデータベースの技術も利用する必要があるというムーブメントのことである」

NoSQLとはSQL（RDB）以外全部を指す。いくつか例が挙げられているがJSONのようなツリー型でもないみたいだ。

※参考：【超入門】RDBとNoSQLの違いに着目！NoSQLに求めるものとは？ - RAKUS Developers Blog | ラクス エンジニアブログ

テーブル型は万能というわけではなく、JSONのようなツリー形式を表現するのはとても難しいらしい。

それでNoSQLが生まれたわけだが、得意分野が異なるトレードオフ、相互補完的な関係のようだ。

※参考：RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！

ちなみにNoSQLの一つMongoDBはJSONみたいなツリー形式！BSONというらしい。*1（2020/02/06追記）

※参考：https://kageura.hatenadiary.jp/entry/2018/01/08/MongoDB%25E4%25BA%258B%25E5%25A7%258B%25E3%2582%2581%25E3%2580%2582%25E5%2580%258B%25E4%25BA%25BA%25E7%259A%2584%25E3%2581%25BE%25E3%2581%25A8%25E3%2582%2581

JSONでやり取りするにはMongoDBにする必要があるのだろうか…？

JSONはRDBとNoSQLの架け橋！

さらに調べるとこちらの記事に出会った！

REST Web サービスの多くは結果を JSON テキスト形式で返し、データを JSON 形式で受け取ります。

JSON 関数を使うと、NoSQL とリレーショナルの概念を同じデータベースに結合できます。 従来のリレーショナル列と JSON テキスト形式のドキュメントを含む列を同じテーブルに結合したり、JSON ドキュメントを解析してリレーショナル構造にインポートしたり、リレーショナル データを JSON テキストに書式設定したりできます。

※参考：JSON データの使用 - SQL Server | Microsoft Docs

なんと！JSONはRDBにもNoSQLにも設定できて、データの架け橋になる！

さらに調べると、今はMySQLもJSON型をサポートしているらしい！

※参考：MySQLでJSON型を使う（基本編） | スマートスタイル TECH BLOG｜データベース＆クラウドの最新技術情報を配信

MySQL＝テーブル型という認識すらも改めた方が良さそうだ。

JSONを返す、とは

RDBからJSONを生成

というわけでRDBとJSONは連携ができるようだ。こちらの記事では実際にテーブルからJSONを生成してる。

mysql => JSON Schemaの自動生成を設計する

テーブルごとのJSON Schemaを生成したい。 とりあえず列名と最大長、必須あたりがあればいいや。

※参考：mysqlのテーブル定義からJSON Schemaを生成する - Qiita

JSONデータでやり取りするからってDBがNoSQLである必要はなく、RDBでも問題ないということか。DBとデータ形式は別概念なんだな。

JSON Schemeとは何か

ところで「JSON Schema」とは何だろう。

JSON Schemaとは名前の通りJSON形式で書かれたSchemaのことです。

Schemaとはデータベースを扱うときによく出てくる単語ですが、簡単に言えば文書をある構造の元、定義したもののことです。

※参考：JSON Schemaの意味や書き方を理解してバリテーションをかけよう！ | 侍エンジニア塾ブログ（Samurai Blog） - プログラミング入門者向けサイト

ふむふむ。JSON形式でDBを扱うときの書き方の決まりということか。

「JSONを返す」とはリクエストに対してJSONでレスポンスすること

ようやく「JSONを返す」のイメージも湧いてきた。

レガシーなWebページ
リクエストを送ると、HTMLとCSS、JavaScriptが返ってきます。

モダンなWebページ
リクエストを送ると、HTMLとCSS、JavaScriptが返ってくるだけでなく、JSONというデータも返ってきます。

※参考：「サーバーサイドエンジニアも知っておくべきフロントエンドの今」をわかりやすくする - Qiita

このJSONの値をJSで操作するとページ全体をリロードすることなく変更箇所のみ非同期に書き換えることができる。

これがAjax通信でありシングルページアプリケーション（SPA）なんだな。

そしてこのDBへのリクエストに使われるのが「axios」や「RxJS」といったライブラリなんだ。

また、JSデフォルトでも「XMLHttpRequest」や「Fetch」などでリクエストをしてJSONを受け取ることごできる。

※参考：[フロントエンド] fetchを用いたAjax通信を行う - YoheiM .NET

やっと全体像が見えてきた！

JSON色付け係

フロントエンドエンジニア＝JSON色付け係

ということで、以前話題になった「フロントエンドエンジニア＝JSON色付け係」という湯婆婆のツイートに繋がるわけだ！

「リクエストするからAPIからJSONを返しておくれ。そこから先はこっちで全部やっておくよー」というのがフロントエンドエンジニア＝JSON色つけ係の仕事、というわけだ！

※参考：JSON色付けたいへん問題 - gaaamiiのブログ

フロントエンドとバックエンドの疎結合

JSON色付けにはなかなか大変さはあるものの、ここから得られるメリットは大きいと感じる。それは「フロント/バックエンドの疎結合化」！

従来のWebシステム開発の場合、サーバサイドでHTMLをレンダリングしていましたが、それによってフロントエンド（見た目）の回収はサーバサイドのシステムへの修正が必要でした。フロントエンドとバックエンドがAPIによって疎結合化することでそうした面倒さはなくなり、HTMLではなくJSONやXMLのように授受されるデータフォーマットを基にした仕様決めが可能になります。

※参考：APIファーストで開発する7つのメリット | NTT Communications Developer Portal

疎結合とは何か

密結合 お互いがごちゃごちゃと絡み合っていて「分けるのが大変だよ～」になっている状態

疎結合 お互いの関わりが薄くて「分けるのが楽チンだよ～」になっている状態

※参考：https://wa3.i-3-i.info/diff452ketugou.html

WordPressなどのCMSや、あるいはRuby on Rails、Laravelなどのバックエンドのフレームワークにはフロントエンドの部品作りも含まれる。フロントエンド部品のみの開発や改修を分業するのは難しい。

REST APIで作ればDBとフロントエンド部品を疎結合化できる。それはバックエンドエンジニア、フロントエンドエンジニア、両方にとってメリットになる！

フロントエンドのみでREST体験（JSON-ServerとFirebase）

ではフロントエンド側でDBやAPIを自作できない場合はどうしたらいいだろうか。

ローカルのNode環境であれば「JSON-Server」というnpm環境が用意されてるみたい。なんと、30秒でできる！？

バックエンドが用意されていない中でアプリケーションのフロントエンドをプロトタイピング

APIのモックを作るだけでも時間がかかりますが、JSON Serverのライブラリーを使うと開発やテスト用の複雑なRESTful APIを速く簡単に作れます。

※参考：たった30秒でREST APIのモックが作れる JSON Serverでフロントエンド開発が捗る – WPJ

クラウドでいうとやはりmBaaSといわれる「FireBase」が有名どころか。

BaaS/mBaaS is何？

基本機能としてどれも「JSONを投げて保存・検索キーでJSON取り出し」がある。

※参考：Firebaseの始め方 - Qiita

なんと！Node.jsのMVCフレームワークExpressでWeb APIが作れる！JSなので読み書きはしやすそう（2020/02/07追記）

※参考：Node.jsとExpressでWeb APIを作ってみよう

まずはここら辺を使いながらRESTを体験していきたく思う。

最後に

ということで、REST APIを取り入れてバックエンドエンジニアとの分業体制を確立すると、自分はフロントエンドのJS開発に集中できることがわかりました。

ゆくゆくの野望がフルスタック！にしても、こういう仕組みがあるんだなー、と知ることで目の前のJS習得に専念できます。

当面はフロントエンドに集中するぞ！それではまた。

※Web開発環境についてまとめ qiita.com

*1:ドキュメント志向データベースと呼ばれている