投稿記事一覧に戻る

RESTってなんだ

これはNITMic Advent Calendar 2021 - Adventarの5日目の記事です。

先日の記事は楽しんで頂けたでしょうか。

え、面白くなかった?

・・・

(´・ω・`)ショボーン

(´・ω・,';,';,',

(´・ω,';,';,',

(´,';,';,',

(,';,';,

';,,('

・・・

少しでも面白いと思ったら、ぜひ『Webを支える技術』という本を読んでみてください。

もっと面白いです。

さて、一応は前回の続きとなりますが、内容は独立しているので、この記事だけ読んでいただいてもかまいません。

はじめに

前回の記事では、Webがそれまでになかった大規模な分散システムであることに触れました。

そして、そのWebのアーキテクチャスタイルはRESTと呼ぶものでした。

しかし、RESTとは何なのか。その説明はしていませんでしたので、今回の記事で説明させていただきます。

(`・ω・´)

RESTとは、ULCODC$SS

(゚Д゚)

※お使いのブラウザは正常です。

わかりにくかったでしょうか。

日本語にすると「統一/階層化/コードオンデマンド/クライアント/キャッシュ/ステートレスサーバ」です。

(゚Д゚)

英語にすると、「Uniform Layered Code on Demand Client Cache Stateless Server」

(゚Д゚)

もういいわ...

...

まってください!いかないで!いかないで!

実は、けっこうわかりやすいんです。

順に説明していきます。

RESTの誕生

とはいっても、まずはRESTの概念の説明からやっていきます。

Webのアーキテクチャスタイルとして知られるRESTですが、その発祥は何なのでしょうか。

答えは、Webのアーキテクチャスタイルそのものなのです。

WebがRESTというアーキテクチャスタイルを元にして作られたのではなく

Webがなぜ大きく成功し、大規模な分散システムが成立したのかについての分析を行い、アーキテクチャスタイルとしてまとめたものこそがRESTなのです。

まとめたのは、Roy FieldingというWebの実装に関わってきた大学院生です。

RESTというアーキテクチャスタイル

Webが「インターネットを通じて公開されたウェブページが相互に接続されたシステム」であるため、そのアーキテクチャスタイルは必然的にネットワークシステムのものとなります。

また、Webは多数のサーバと多数のクライアント(ブラウザ)からなっているので、クライアント/サーバというアーキテクチャスタイルになっていると言えるでしょう。

このことから、RESTというアーキテクチャスタイルはクライアント/サーバの一部であるという予想ができます。

そしてその予想は正しく、RESTはクライアント/サーバというアーキテクチャスタイルの一部です。

他にクライアント/サーバーとしてよく知られるものとして、P2Pアプリケーションがあるのではないでしょうか。

こちらは、クライアント/キュー/クライアントという、サーバがデータを保持するキューとして振る舞うものから発展したものです。

「詳しくはWebで!」

さて、RESTがクライアント/サーバの一部だということは、クライアント/サーバに制約を加えるとRESTになることが想像できます。

まさにその通りです。

では、実際にどのような制約が課されているのでしょうか。

ULCODC$SSという制約

さて、はじめのほうに、RESTとはULCODC$SSである、と書きました。

日本語では「統一/階層化/コードオンデマンド/クライアント/キャッシュ/ステートレスサーバ」

でしたね。

実は、これこそが制約なのです。

クライアント/サーバにどんどん制約を加えていくことで、最終的にULCODC$SSになるという事を説明していきます。

(ここからの内容は、『Webを支える技術』の3.4"スタイルを組み合わせてRESTを構成する"をまとめたものになります。図解でとても分かり易いので、是非『Webを支える技術』原本で読んでみてください。)

CS(クライアント/サーバ)

まず、基本となるクライアント/サーバから説明していきます。

クライアントはユーザーインターフェースを担当し、サーバがデータストレージを担当します。

これにより、クライアントをゲーム機や携帯電話など様々なプラットフォームにすることが可能で、サーバもUIを提供しなくてよくなり、また複数サーバで冗長化することで可用性を上げることもできます。

クライアントはサーバにリクエストを送り、サーバはそれに対するレスポンスを返すというアーキテクチャスタイルです。

CSS(クライアント/ステートレスサーバ)

先ほどのクライアント/サーバに、ステートレスサーバという制約を加えます。

ステートレスサーバとは、「クライアントのアプリケーション状態をサーバで管理しないこと」です。

ただ、抽象的でわかりにくいと思われるので会話による例を挙げます。

ステートフルな例

A「今日のご飯はなにがいい?」

B「カレーライス」

A「具材はなにがいい?」

B「チキンとナス」

A「何時に食べる?」

B「19時」

こちらがステートフルな例です。普通の会話ですね。

ステートレスな例

A「今日のご飯はなにがいい?」

B「カレーライス」

A「具材はなにがいい?」

B「チキンとナスのカレーライス」

A「何時に食べる?」

B「19時にチキンとナスのカレーライスを食べる」

こちらがステートレスな例です。冗長だと感じるでしょう。

このことから、ステートレスサーバとは、「サーバがそれまでの会話の内容は覚えない。クライアントがすべての会話を繰り返す。」ようなものであると想像できます。

冗長じゃないほうがいいじゃん!と思うかもしれませんが、欠点ももちろんあります。

是非『Webを支える技術』6.7"HTTPのステートレス性"を読んでみてください。

私は納得しました。とても面白いです。

まとめるのが面倒臭い訳じゃないよ

ともかく、このような制約をクライアント/サーバに加えたものがCSS(クライアント/ステートレスサーバ)になります。

C$SS(クライアント/キャッシュ/ステートレスサーバ)

先ほどのCSSに、キャッシュ(Cache)という制約を加えます。

よく「キャッシュを消去」と耳にするかもしれません。

そのキャッシュです。

これは、サーバからのレスポンスの主な内容(今回はこれをリソースと呼ぶことにします)の鮮度に基づいて、以前に取得したリソースを使い回す方式です。

リソースに特に変更がなされていない場合は、クライアントに保存してあるリソースを利用します。

これにより、パフォーマンスの上昇とネットワークへの負荷の軽減がなされます。

UC$SS

統一/クライアント/キャッシュ/ステートレスサーバ

いよいよ長くなってきました。先ほどのC$SSに、統一インターフェースという制約を課しました。

これは、リソースに対する操作を、統一した限定的なインターフェース(入出力部分)で行うというものです。

例えば、リソースを読みたい場合はGET、消したい場合はDELETEなど、CRUDに対応した8個のメソッドのみで操作します。

これだけ数が限られているということは、当然ひとつあたりの操作の粒度は大きいです。なので、オーバーヘッドがあまり発生せず性能低下の問題が解決できます。

また、インターフェース(入出力部分)を限定的なものに統一することで、クライアントとサーバの独立性が向上します。

これによるメリットは、多様なクライアントやサーバで実装が容易になることでしょう。(クライアントとサーバの独立性が高く、インターフェースも固定されているため、サーバがクライアントの特徴を知る必要がないし、逆にクライアントがサーバの特徴を知る必要もない。そのために、多種多様なデバイスや言語で開発する事が容易になることでしょう。)

・・・

(/・ω・\)

・・・

わかりにくいかもしれない...

ULC$SS

統一/階層化/クライアント/キャッシュ/ステートレスサーバ

先ほどのUC$SSに、階層化という制約を課しました。

これは、サーバとクライアントの間に、ロードバランサ(サーバにかかる負荷を効率よく複数のサーバに分散させることで軽減する装置)や、プロキシ(主にセキュリティなどの問題で、直接インターネットに接続できないコンピューターの代理としてWebなどにアクセスするサーバ)を挟むなど、システムを複数の階層に分割できるという制約です。

長い!!!

つまり、クライアントから直接ステートレスサーバに接続するだけでなく、間にサーバなどを挟んでも大丈夫!ということです。

これが実装可能なのは、先に課した制約である「統一インターフェース」のおかげです。

クライアントから見れば、ステートレスサーバもプロキシもロードバランサも、同一のインターフェースで接続できるので、相手がどんな役割のサーバかを意識せずに接続できます。

このことが、この「階層化」の実装に一役買っている訳ですね。

ULCODC$SS

統一/階層化/コードオンデマンド/クライアント/キャッシュ/ステートレスサーバ

いよいよ最後の制約です。先ほどのULC$SSに、コードオンデマンドという制約を加えます。

コードオンデマンドというのは、プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するというものです。

これにより、CSRなどのJavaScriptなどでクライアント(ブラウザ)標準以外の機能も実装できるようになりました。

(CSRなどについては、12/13に記事を出そうと思っています。)

RESTとは、ULCODC$SS

(*´ω`*)

ね、簡単でしょ?

以上がRESTが何なのか、という説明になります。

クライアント/サーバに各種の制約を加えた「ULCODC$SS」というアーキテクチャスタイルに名前をつけたものが「REST」なのです。

このRESTというアーキテクチャスタイルは、今やWebだけでなく、Web APIなどにも応用され、活用されています。

また、"Web APIが「RESTful」(RESTの制約に従っていること)であれば、Webは全体としてよりよくなる"とも『Webを支える技術』には書かれています。

(一方、全面的にRESTに従って可用性が損なわれるのも問題であるとも記されています。)

わたしの感想

Webが拡大の一途をたどり、ハイパーメディアとしても分散システムとしても未曾有の大成功を収めたのは、その「シンプルさ」故でしょう。

はじめ、この言葉を聞いたときは

ヽ(`Д´#)ノ Webがシンプルなわけないじゃん!!

と思いました。

しかし、多くの制約を課し、インターフェースに至っては8つ(実質6つ)まで絞って統一してシンプルにしたからこそ、Webは大成功したのだなと大変納得しました。

この感動をどうにかして共有したいと思い、記事にしてみましたがどうでしたでしょうか。

少しでも「へぇ~」とか「なるほどなぁ」と思っていただけたら恐縮です。

わかりにくいと感じた場合はぜひ『Webを支える技術』原本を読んでみてください。他にもかなり面白い(特に歴史について)記述がありました。

Web関連では、コードオンデマンドの説明に少し出てきたCSR(Client Side Rendering)などについて、AdventCalenderで記事を出します。

Twitterなどがどうやって実装されているのか、わかるかもしれません。

では、次は「オブジェクト指向でプログラムを書く」にて会いましょう。

長々とお付き合いありがとうございました。

参考

書籍(Amazonにリンクします)

Webを支える技術 ―― HTTP,URI,HTML,そしてREST Web+DB PRESS plus

餅草 よもぎ

物を作る/競争が苦手/徐々にレイヤが下がっていく

本当にお気軽にDMください。

Twitter:@kusa_yomogi
GitHub:Sora513
LottieFiles:Sora513
Powered by