数年前からキーワードとしては知っていた「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先生で翻訳すると「代表的な国家移転」となった。
国家を移転するとはまたずいぶん大それた話w しかしこのStateはおそらく国家という意味ではない。
RESTの原則
- アドレス可能性(Addressability)
提供する情報がURIを通して表現できること。全ての情報はURIで表現される一意なアドレスを持っていること。- ステートレス性(Stateless)
HTTPをベースにしたステートレスなクライアント/サーバプロトコルであること。セッション等の状態管理はせず、やり取りされる情報はそれ自体で完結して解釈できること。- 接続性(Connectability)
情報の内部に、別の情報や(その情報の別の)状態へのリンクを含めることができること。- 統一インターフェース(Uniform Interface)
情報の操作(取得、作成、更新、削除)は全てHTTPメソッド(GET、POST、PUT、DELETE)を利用すること。
ふむふむ、RESTのSのStateは国家ではなくこの「ステートレス」から来ているんだな。
ちなみにこの4原則が全て揃った状態を「RESTful」というが「REST」とほぼ同義と考えて良さそうだ。
ステートレスとは何か
ステートレスについても調べる。まず「ステート」とは何か。
ITの分野では「状態」の意味で用いられることが多い。
ITにおける「ステート」は国家ではなく「状態」を意味するようだ。
で、ステートには「ステートフル」と「ステートレス」の2種類がある。
ステートフルとは、状況によって、あるリクエストをしたら、レスポンス(対応や反応、応答内容等)が変わるもの。
ステートレスとは、状況によらず、あるリクエストをしたら、必ず同じ結果になるもの。特に、それまでのリクエスト・レスポンスのことは一切考えず、今来たリクエストを額面通りに受け取って回答するもの
※参考:【初心者向け】ステートフル(Stateful)とステートレス(Stateless)の違い,IPv6やAWSでの考え方│SEの道標
そして、普段慣れ親しんでいるHTTP通信は「ステートレス」というわけだ。
ステートレスについてはこちらの記事が分かりやすかった。
(ステートレスの例):
客: こんにちは
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとジンジャーエールでお願いします
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします
店員: 以上でよろしいですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上
店員: かしこまりました
ハンバーガー店で、メニューの指定をするたびにいちいち最初から全部の品名を伝えるお客さん。
一見うざったそうだがw これによって店側にとっては注文の途中で店員さんを入れ替えてもメニューが正確に伝わるわけだ。
- リクエストには、処理に必要な情報を含む
ステートフルとは異なり、自己完結型である- サーバ資源をすぐに開放できるという利点があり、利用者や負荷におういて性能や機能を向上させられる
- アプリケーションの状態を覚える必要がないため、サーバ側のシステムは単純になる
フロントとバックを分けるからこそのテクなんだろうなと。
※参考:ステートレスとは - Qiita
RESTはアーキテクチャだった
アーキテクチャスタイル「REST」とは何か
という記事があって、このタイトルによってRESTはアーキテクチャだとわかる。
※参考:アーキテクチャスタイル「REST」とは何か | Think IT(シンクイット)
では、アーキテクチャとは何か。
「アーキテクチャ」は英語の「architecture」のことで、大きく分けて3つの意味に分かれます。
1つは学問としての「建築学」で、総合建築を学ぶ大学での専門分野のこと。2つ目は建築そのものを指し、「建築構造」「建築様式」「建築術」などを意味しています。そして3つ目が建築という軸の意味から派生して生まれた「ソフトウェア、またはハードウェアの基本的な設計概念」という意味での「アーキテクチャ」です。
※参考: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)
(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が使われる。
では、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追記)
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色付け係」という湯婆婆のツイートに繋がるわけだ!
湯婆婆「フン。フロントエンドエンジニアというのかい?」
— ぷーじ (@YuG1224) 2019年9月15日
フロントエンドエンジニア「はい」
湯婆婆「贅沢な名だねぇ。今からおまえの名前は "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取り出し」がある。
なんと!Node.jsのMVCフレームワークExpressでWeb APIが作れる!JSなので読み書きはしやすそう(2020/02/07追記)
※参考:Node.jsとExpressでWeb APIを作ってみよう
まずはここら辺を使いながらRESTを体験していきたく思う。
最後に
ということで、REST APIを取り入れてバックエンドエンジニアとの分業体制を確立すると、自分はフロントエンドのJS開発に集中できることがわかりました。
ゆくゆくの野望がフルスタック!にしても、こういう仕組みがあるんだなー、と知ることで目の前のJS習得に専念できます。
当面はフロントエンドに集中するぞ!それではまた。
※Web開発環境についてまとめ qiita.com
*1:ドキュメント志向データベースと呼ばれている