はじめに
自分はWebの基礎を固めないままエンジニアとして過ごしていました。
そのことに焦燥感を感じることが多いため、今回 技術評論社 から出版されている Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) を要約する連載することにしました。
今回は第2章の要約となります。
前回 - 【連載】へっぽこエンジニアが「Webを支える技術」を要約してみた（第2章）
対象読者
「はじめに」を読んで心当たりのあるエンジニアの方。
第3章 REST Webのアーキテクチャスタイル
3.1 アーキテクチャスタイルの重要性
- RESTはWebのアーキテクチャスタイル
- アーキテクチャスタイルは複数のアーキテクチャに共通する性質・仕様・流儀などのことを指し、
システムのアーキテクチャを決定する際の指針となる
3.2 アーキテクチャスタイルとしてのREST
- RESTは、クライアント/サーバのアーキテクチャスタイルを基にいくつかの制約を加えたもの
- Webのアーキテクチャスタイル/アーキテクチャ/実装の分類は下記の通り
| 抽象化レベル | Webでの例 |
|---|---|
| アーキテクチャスタイル | REST |
| アーキテクチャ | ブラウザ、サーバ、プロキシ、HTTP、URI、HTML |
| 実装 | Apache、Firefox、IE |
3.3 リソース
- リソースはWeb上の情報のこと
- リソースはそれぞれURIで一意の名前を持つ
- URIを用いることで、プログラムはリソースの表現する情報にアクセスできる
リソースの名前としてのURI
- リソースの名前とは、URIのこと
リソースのアドレス可能性
- アドレス可能性とは、URIによってリソースを簡単に指し示すことのできる性質のこと
複数のURIを持つリソース
- 現在が2020年9月1日だとすると、下記の2つのURIは同じリソースを指す
http://weather.example.jp/tokyo/today
http://weather.example.jp/tokyo/2020-09-01 - リソースに複数のURIをつけるとクライアントがリソースにアクセスしやすくなるが、
どれが正式なURIか分からなくなる
リソースの表現と状態
- サーバとクライアント間でやりとりするデータのことを「リソースの表現」と呼ぶ
- HTML形式、PDF形式、テキスト形式など
- 天気予報、株価などの過去現在未来の情報
3.4 スタイルを組み合わせてRESTを構成する
クライアント / サーバ
- クライアントとサーバを分離して処理できるので、
クライアントをマルチプラットフォームできる
- PC、スマートフォン、ゲーム機など
ステートレスサーバ
- クライアントのアプリケーション状態をサーバで管理しないこと
-
ステートレスではない例としてCookieを使ったセッション管理やフォーム認証があげられる
これらは必要最低限にするべきである
キャッシュ
- 一度取得したリソースをクライアント側で使い回すこと
- サーバとクライアント間の通信を減らすことができるが、
古いキャッシュを利用して情報の信頼性が下がることがある
統一インタフェース
- URIで指し示したリソースに対する操作を限定的なインタフェースで行うことで、 サーバとクライアントの独立性を向上させる
- HTTP1.1のリクエストメソッドが8つだけとなっている
階層化システム
- サーバとクライアント間に独立したシステムを設置できること
- ロードバランサを用いて負荷分散
- プロキシを用いてアクセス制限
コードオンデマンド
- JavaScriptのように、サーバからプログラムコードをダウンロードしクライアントで実行すること
- クライアントを後から拡張できることが魅力だが、
HTTPにしたがって通信が行われないためプロトコルの可視性が低下する
REST = ULCODC$SS
- RESTとは上記6つのアーキテクチャスタイルを組み合わせたもので、
ULCODC$SSと呼ばれることもある
今回のうろ覚えワード
-
ロードバランサ
複数のサーバを利用している際、
各サーバの処理負荷を分散させるために誘導をするもの -
プロキシ
クライアントの代わりにサーバにリクエストを送ることができ、
クライアントの身元を隠せたりアクセスを制限したりすることができる
感想
-
3.4 スタイルを組み合わせてRESTを構成する で、
今まで曖昧だったRESTの意味を理解することができた