Webを支える技術は難しい？第一部〜第三部までわかりやすく要約

Web技術者のバイブルとして知られている名著「Webを支える技術」ですが、巷では難しすぎて読めない、初心者にはおすすめできない、などと言った声が見受けられます。

私YUUKIはWebエンジニアになって一年が経とうとしていますが、そろそろWebを支える技術を読んでも理解できるぐらいのエンジニアになったのでは、と思ったので購入してみました。

そしてこの度、前半部分を読み終わりましたので、アウトプットも兼ねて内容をわかりやすく要約していきます。

※後半部分はこちら

Webを支える技術の4部5部を要約。Webサービス設計者にはおすすめの技術書！

今回の4部と5部では、ハイパーメディアフォーマットのHTMLと、Webサービスの設計方法についてまとめています。 実際にWebサービスを作っている方には参考になる部分が多いと思いますので、自身の経験と照らし合わせて読んでみてください。

tech.cloud-blazer.com

2020.01.15

1部〜3部までの目次

• 1部 Web概論
  • 1章 Webとは何か
  • 2章 Webの歴史
  • 3章 REST Webアーキテクチャスタイル
• 2部 URI
  • 4章 URIの仕様
  • 5章 URIの設計
• 3部 HTTP
  • 6章 HTTPの基本
  • 7章 HTTPメソッド
  • 8章 ステータスコード
  • 9章 HTTPヘッダ

1部 Web概論

Webとは何か、Webの歴史からWebのアーキテクチャスタイルとして有名なRESTについて解説してある。

Webとは、World Wide Webの略称で、インターネットを通じて世界中の様々な情報にアクセスする為のソフトウェア/技術のことである。

Webには３つの用途がある。一つはWebサイト、２つ目はユーザーインターフェイスとしてのWeb、３つ目はプログラム用API（Web API）である。

Webには、HTTP、URI、HTMLという３つの概念があり、それら３つが「Webを支える技術」である。

WebはHTTPというシンプルなプロトコルを用いたからこそ大規模なシステムになった。

Web以前にも分散システムで流行ったものにRPCシステムがあるが、性能劣化や負荷分散の問題点があり、大規模なシステムとしてスケールしなかった。そこで、1990年にスイスのCERN研究所で働いていたティムバーナーズリーが、世界初のWebの提案書を書き、Webブラウザとサーバを完成させた。

このWebが流行したキッカケがイリノイ大学の学生らが製作したMosaicというブラウザ。

Mosaicは、当初のブラウザが文書のみしか扱えなかったのに対し、画像を混在させることが出来た為流行し、その後のNetscape Navigator（Mosaic開発に携わった学生らが別会社を立ち上げ作成した）や、IEに多大な影響を与えた。

Webが商業的な成功を抑えた後、2000年にはインターネットのクライアント・サーバーシステムにある制限を掛けたWebインターフェイスとして、「REST」という概念が生み出された。

RESTには以下の特徴がある。

1. クライアントがリクエストしたデータをサーバがレスポンスする
2. インターフェイスが統一されている（HTTPプロトコルが使用）
3. ステートレスである（サーバ側がクライアントの状態を待たない）
4. 階層型システムである（クライアントサーバ間が階層型でいくつかシステムが存在する）
5. キャッシュがある（一度取得したリソース（Web上の一意の情報）をクライアントが繰り返し使用する）
6. コードオンデマンドである（JSなどの言語のコードをサーバが保存している場合、クライアントで実行する）

2部 URI

URIとは何か/設計の仕方を解説している。

URIとは、Web上のリソース（一意の情報）を識別する概念である。

URIの実装には、クライアント側で相対パスと絶対パスの混同による読み込み方式の違いを考慮したり、日本語の文字時など、URIが認識出来ない文字を%エンコーディングする際に、クライアントに依存する部分を解消する（例えば現在主流の文字コード UTF-8に統一する など）対策を考慮する必要がある。

URIの他には、URL/URNがある。
URIがWeb上の情報を一意に識別するという概念に対し、URLはリソースの場所を示すもの、という違いがある。
URNは普及はしていないが、URIを恒久的なリソースとするIDを割り振った概念である。

URIの設計の仕方の章では、以下のような思想を学んだ。

• URIのリソースの拡張子は隠蔽したほうがセキュリテイ的に良い（.phpなどの拡張子は含めない）
• URIは冗長ではなく、完結に意味の分かりやすい物にするべき
• URIはクライアント側で操作すべきではなく、サーバ側で実装すべき
• クライアントはあくまでURIを参照するだけに留まらせておくべきであるが、一方、日本語や英語など言語の違いによってパス末尾の名前を変えるだけで、ユーザーエージェント（ブラウザ）が簡単に異なる言語を識別できるコンテントネゴシエーションや、URIを階層構造ではなく二次元の構造となるマトリクスURIなども存在する。

3部 HTTP

HTTPの基本から、TCP/IPのプロトコルとネットワークの層のそれぞれの関係性、HTTPの歴史、クライアントサーバシステムがどのようにリクエスト-レスポンスを行うのか、詳細に解説している。
この部では、以下４つに焦点を当てて解説されている。

• HTTPの概要
• HTTPメソッド
• HTTPステータスコード
• HTTPヘッダ

順番に解説する。

HTTPの概要

HTTPはクライアント/サーバシステムのプロトコル。
クライアントは、サーバに対してリクエストをし、情報を得るが、クライアントはリクエストするだけでなく、受けたレスポンスの情報を一度解析してユーザーエージェント（ブラウザ）に届ける。
クライアント/サーバ間では、HTTPを通して「HTTPメッセージ」が行き来している。

なお、HTTPメッセージは以下の構造で出来ている。

• スタートライン
• ヘッダ
• 空行
• ボディ

クライアント/サーバの状態には、ステートレスとステートフルというのがある。
それぞれのメリット・デメリットは以下の通り。

• ステートレス
  • デメリット：セッション状態を保持できない
  • メリット：自己記述的メッセージでクライアントのリクエストに全て必要な情報が含まれている
• ステートフル
  • デメリット：サーバを複数に増やした時に設計が複雑になりやすい
  • メリット：通信エラーが起きても、その前のリクエスト情報をサーバが覚えている為、エラー回避出来る可能性が高い

HTTPメソッド

HTTPメソッドには以下8つの種類がある。

• GET
• POST
• PUT
• DELETE
• HEAD
• OPTIONS
• TRACE
• CONNECT

GET/POST/PUT/DELETEがDBへの問い合わせのCRUDに対応する。
HTTPメソッドは作れるが、プログラマーは無闇に増やさず、出来るだけ現存するメソッドを使用することが推奨されている。

HTTPメソッドの各特徴は以下の通り。

• GETは最も使用頻度の高いメソッドで、リソースを取得する。
• POST/PUTはリソースの生成/更新に使われる
• POSTはクライアントがリソースのURIを指定出来ないのに対し、PUTはクライアントで指定できる。つまり、Twitterのような想定出来ないURIが生成されるWebサービスの設計ではPOSTを、Wikipediaのような想定出来るURIの生成にはPUTを使用する。
• HTTPメソッドにはべき等と安全性という２つの特性がある。
• べき等とは、何度リクエストしてもリソースの結果が変わらないことを指す
• 安全性とは、リソースに変更を加えない（更新/削除しない）ことを指す。
• GETはべき等と安全性の２つの特性があり、PUT/DELETEは安全ではないがべき等である。POSTは安全でもべき等でもない

また、 example.comのようなリクエストのテスト用ドメインがあり、そちらを使用することでHTTPメソッドの試験を行う事ができる。

HTTPステータスコード

ステータスコードとは、クライアントとサーバーの状態を表すもの。

ステータスコードには1xx系から5xx系まであり、1系は処理中、2系は成功、3系はリダイレクト、4系はクライアントエラー、5系はサーバエラーと区別され、ステータスコードの先頭数値で大まかなエラー種別を判別出来る。

使用頻度の高いステータスコードに、200(リクエストOK)、201（リソースの作成成功）、301（恒久的なリソースの移動）、303（別URIの参照 POSTで作成したリソースのレスポンスを異なるURIでGETで取得する）400 リクエストの間違い、401(認証失敗)、404(Not Found)リソースが見つからない、500(Internal Server Errror)サーバ内部エラー、503(Service Unavailable)サービス停止、などがある。

これらのステータスコードには4系5系であればエラー処理を自分で追加することも出来る。その際は、プロトコルに従ったフォーマットでエラーを返すのが重要であり、メディア種別タイプがAtom形式であればAtomを、HTML形式であればHTML形式で返す必要があり、また、200でリソースの取得に成功しているにも関わらず、レスポンスボディにエラーメッセージを含めるなどするのは良くない。理由として、WebAPIであれば、こういったエラーをWebAPI側の意図通り実装するには専用のクライアントを実装する必要があり、そうなると様々なクライアントで利用できるというWeb APIの利点を損ってしまう。

つまり、ステータスコードは概念や決められたルールに従って実装する必要があるというのが、本項で述べたい内容である。

HTTPヘッダ

HTTPで使われるヘッダは、ボディに対する付加的な情報で、サーバはヘッダを見てメッセージに対する挙動を決定する。
ヘッダを学ぶ上でメール・メッセージの仕様も共に学ぶ必要があり、その理由はHTTPはメールと共に成長してきたから。メールプロトコルとヘッダには明確な違いが有り、それはメールは一方向のやり取りに対し、ヘッダはリクエスト/レスポンスのやり取りがある点。

ヘッダには主に以下の情報が付加したり、仕様することが出来る

• 日付
• MIMEメディアタイプ
• 言語タグ
• コンテントネゴシエーション
• チャンク転送
• 認証
• キャッシュ
• 持続的接続

また、ファイル名を明示的に指示することもできる。ただし、HTTPヘッダを活用するためには、電子メールや言語タグ、文字エンコーディングなど、他のノウハウを学び、それらの歴史と実際のサーバやブラウザの実装を調査する能力が必要となる。

Webを支える技術の1部〜3部を読んでみて

全体として今まで触り部分しか知らなかったWeb技術をより深く知ることが出来ました。
特に、「URIの設計思想」については、自分が開発中のWebアプリケーションに活かせそうな知識が多く、大変参考になりました。

これからWeb技術者を目指そうと思っている方や、現在Webエンジニアとして働いている方にはオススメの名著です。