Webを支える技術①~RESTとは~

よくオススメされてる「Webを支える技術」を最近読んだのでまとめる。

その後、「Web技術の基本」という本もオススメされて読んだがこちらの方が基礎的でわかりやすかった。

Webを支える技術
→Web技術の基本
→Webを支える技術(2回目)

という順序で読んだが、Web技術の基本から読むことを強くオススメする。

　

結論、Webを支える技術は以下の3つ

全てを一つの記事でまとめると膨大な量になるので、まずはこの記事では概論をまとめることにする。
それだけでも6000字の中々のボリューム。。。

別記事でHTTPについてとURIについてをまとめる。
HTMLはまとめるほどのものでもないなって思ったのと、他のAtomとかなんやかんやはよくわからんて感じだったのでとりあえずは放置の方向で。

つまり本記事を入れて全部で3部作になる。

URIについてはこちら

https://www.sunapro.com/web%e3%82%92%e6%94%af%e3%81%88%e3%82%8b%e6%8a%80%e8%a1%93%e2%91%a1uri/

HTTPについてはこちら

https://www.sunapro.com/web%e3%82%92%e6%94%af%e3%81%88%e3%82%8b%e6%8a%80%e8%a1%93%e2%91%a2http/

今回は概論だが主にRESTについての説明。

情報システムとしてのweb

webを情報システムとして見ると以下の2つの側面を持っている。

1. ハイパーメディアシステム
2. 分散システム

ハイパーメディアシステム

ハイパーメディアとはテキストや画像などの様々なメディアをハイパーリンクで結びつけたシステム。

ざっくり言ってしまうと、いろんな情報がハイパーリンクで繋がってるシステム。
webとweb以前のハイパーメディアとの一番の違いはインターネットを使っているかどうか。

webはインターネットを用いることで様々な情報をリンクさせることができ、システムを大規模化しやすくなっている。

webはクモの巣を意味する。
まさにクモの巣のようにいろんな情報が結びついている。

分散システム

分散システムは複数のコンピュータをネットワーク上に分散して配置し、効率的に処理するようにしたシステム。
対義語は集中システムで、1つのコンピュータが様々なあらゆる処理を行うというもの。

webは世界中に配置されたサーバーに世界中のブラウザがアクセスする分散システム。

それまでの分散システムは広まらなかった一方で、webがここまで広まったのはプロトコルがシンプルだったから。
それまでの分散システムでは負荷分散の問題など様々な問題があったが、webではHTTPというシンプルなプロトコルを使うことにより、これらの問題を解決することができた。

シンプルイズベスト。
後々のキーワードにもなるが、あらゆる”制約“によって必要最低限のシンプルさを保つというのは標準化を行う上で重要であり、それによって広く普及する技術となりうる。

根幹となる技術はシンプルであるべきなんだなと思った。
シンプルであればその上でいかようにも派生できる。

目玉焼きはシンプルだからこそ塩、醤油、ソースなど色んな味付けができるけど、もしあれが最初から味噌を練り込むメニューですとかだったら普及しないだろうな。。

ちなみに目玉焼きは醤油派。

RESTとは

RESTはRepresentational State Transferの略。

webの急速な普及に伴い、各社がそれぞれ勝手に独自のスパイスを混ぜていくと相互運用できなくなる。
そのため、あらかじめある程度のガイドラインを定めてそれに沿ってwebを設計する必要がでてきた。
このweb標準化のために様々な設計思想が提案されたが、その中で現在最も普及したのがRESTというわけである。

それぞれが勝手なことするとまとまりなくなるから、機能性は担保しつつ簡潔なルールを設けましょうという話。

つまりRESTはwebの設計思想でありアーキテクチャスタイルである。

アーキテクチャスタイルとはアーキテクチャより抽象度が一つ高いもの。
アーキテクチャにはブラウザ、サーバ、HTTP、HTMLなどがある。
これらを組み合わせてwebを設計しましょうってのが、アーキテクチャスタイルであるRESTがざっくり意味するところ。

抽象度	webでの例
アーキテクチャスタイル	REST
アーキテクチャ	ブラウザ、サーバ、HTTP、HTML
実装	Apache、Google Chrome

ちなみにRESTはネットワークシステムのアーキテクチャスタイルであって
それ以外の例だとMVC(model-view-controller)とかもアーキテクチャスタイルのレイヤーになるらしい。
同じネットワークシステムの別のアーキテクチャスタイルだとP2Pなど。
ブロックチェーンで使われるやつ。

詳細は後述するが、RESTというのはクライアント/ サーバのアーキテクチャスタイルにいくつかの”制約“を加えたものである。
制約を加えることで、組み合わされたそれぞれのコンポーネントが好き勝手動作することなく、全体で強調して動作するようにできる。

リソースとは

RESTについての説明に入る前に、リソースの説明をしておく。
リソースはRESTにおける重要な概念の一つ。

一言で言うと、「web上に存在する、名前を持ったありとあらゆる情報」である。

それぞれのリソースは一意のURIを持ち、このURIを用いることでプログラムはリソースが表現する情報にアクセスできる。

このURIが持つ、リソースを簡単に指し示せる性質のことをアドレス可能性と呼ぶ。
つまり、名前がちゃんと付いてて適切な手段でアクセスできる状態であること。

ちなみにURIとURLは厳密には違うが、URIをURLに読み替えても支障はない。

リソースとは「web上に存在する情報」という抽象的な概念であり、具体的にクライアントとサーバ間でやりとりするデータのことをリソースの表現と呼ぶ。

なんやかんや書いたけど、リソースってのは情報のことなんだなくらいわかってればいい気もする。

RESTの構成

先述したようにRESTとはクライアント/ サーバにいくつかの制約を課して構成されている。
そのために、いくつかのアーキテクチャスタイルが組み合わされて構成されている。

結論、RESTは次の6つを組み合わせたアーキテクチャスタイルである。

図にするとこんな感じになる。

以下で一つずつ詳細に記述する。

クライアント/ サーバー

省略。

ステートレスサーバー

ステートレス: クライアントのアプリケーション状態をサーバ側で管理しないこと。
ステートフル: クライアントのアプリケーション状態をサーバ側で管理すること。

つまりステートフルだと、同じクライアントから2回目以降アクセスがあった時に前の状態を記憶しているということ。

以下はステートレスの場合のクライアント/ サーバの例。

ファストフード店での注文で

えぇ。。。(困惑)

こう見るとステートフルにすべきって感じもするが、これのデメリットはサーバの数が増えた時に、クライアントの状態管理を全てのサーバ間で同期しないといけなくなる。
あるいは同一クライアントからのアクセスは必ず同一サーバに振り分けるような仕組みを導入しなければならない。

要するにサーバ側の負荷が高くなる。

ステートレスであれば、クライアントの情報は持たなくていいのでサーバ側の実装を簡略化できる。

しかし、UX的にはステートフルの方がいいことも多々あり、HTTPをステートフルにする代表的な方法はCookieを使ったセッション管理。

これは厳密にはRESTの視点から見ると間違っているが、UXを考えると使わざるを得ない場合もある。

キャッシュ

取得したリソースの鮮度に基づき、それをクライアント側で使い回す方式。

これにより、クライアントとサーバ間の通信量を減らすことができる。

統一インターフェース

リソースに対して統一された限定的なインターフェースで操作を行うアーキテクチャスタイルのこと。

たとえばHTTPではGET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECTの8つのメソッドのみが使える。

たったこれだけに限定されているため、様々なアーキテクチャ間のやりとりが統一され、全体のアーキテクチャがシンプルになる。
また、インターフェースが統一されることで、クライアントやサーバの実装の独立性が向上する。

webが多様なクライアントやサーバで実装されているのは、統一インターフェースが重要な役割を占めており、RESTを最も特徴付けるアーキテクチャスタイル。

階層化システム

システムを階層化し、しかもそれが統一インターフェースで接続できることで、クライアントはサーバもプロキシも同じインターフェースで接続できる。
つまり、クライアントは接続先が変わったことを意識しなくて良くなる。

コードオンデマンド

プログラムをサーバからダウンロードし、クライアント側で実行するアーキテクチャスタイル。

クライアントを後から拡張できるが、アプリケーションプロトコルの可視性が低下する。
HTTPの間は通信の意味が明確だったが、クライアント側でプログラムを実行すると通信内容が不透明になる。

RESTfulなWebサービス

ここまででRESTの構成を見てきたが、RESTはあくまでアーキテクチャスタイルなのでこれを基にして色々と調整してよい。

RESTの規約に基づいていてRESTらしいことをRESTfulという。

なんか結構定義曖昧だな。。

別の書籍ではRESTfulなWebサービスの性質として、アドレス可能性、ステートレス性、持続性、統一インターフェースの4つを挙げている。
持続性以外は本文中で述べた。

持続性とはリソースをリンクで接続して1つのアプリケーションをなすという性質。
要はハイパーリンクでつながってるよってことかな。

重要性としては
アドレス可能性 > 持続性 > 統一インターフェース > ステートレス性

おわりに

次回以降の記事でそれぞれの技術を詳しく見ていく。

URIについてはこちら

https://www.sunapro.com/web%e3%82%92%e6%94%af%e3%81%88%e3%82%8b%e6%8a%80%e8%a1%93%e2%91%a1uri/

HTTPについてはこちら

https://www.sunapro.com/web%e3%82%92%e6%94%af%e3%81%88%e3%82%8b%e6%8a%80%e8%a1%93%e2%91%a2http/

参考

• Webを支える技術(書籍)
  https://amzn.to/2AYsEy7

• Web技術の基本(書籍)
  https://amzn.to/2YhQsFX