ホーム
BLOG
未分類
『Webを支える技術』を読んだ学び

『Webを支える技術』を読んだ学び

はじめに
事前に知っておいた方が良かったこと
本書の構成について
気になった点
おわりに

はじめに

自分は元々組み込み・アプリケーション系のエンジニアでしたが、Web系のこともやっていきたいなと思ったので改めて学習することにしました。
Webの基礎を体系的に学習する上で参考になる本を先輩やAIに聞いたところいくつかの候補があり、その中でも『Webを支える技術』という本が会社にもあったため良い機会として学習しました。

Webを支える技術 | 技術評論社

全5部、17章となっており、堅い感じの教科書的本でしたが何とか読み終えることができました。
今回はWeb知識ほぼ0で読んだ感想などを書いていこうと思います。

事前に知っておいた方が良かったこと

この本は丁寧に解説してあり新しい単語なども定義から示してくれたりするのですが、それでも若干躓いたところがありました。
その例を以下に示します。

URI

第2部、4章でURIについての定義や説明などを行ってくれています。
ですが第1部の時から、つまり定義が分からないまま頻繁に使用されていました。

URLについては日々インターネットを使っていれば理解しているので、まず前置きで「URLのようなもの」とでも簡単に説明してくれていたらスムーズに読めたかなと思いました。

こちらについては4章最後のコラムで書かれていました。

URIと似た名前としてURL(Uniform Resource Locator)があります。
本書ではここまで一貫してURIという名前を使ってきましたが、これをURLと読み替えても問題ありません。
しかし正確には、URIはURLとURN(Uniform Resource Name)を総称する名前です。

こだわりをもって書き分けを行っていたようですが、もっと早い段階でコラムを書いても良かったんじゃないかと思いました。

WebAPI

こちらの単語は本書で終始登場していました。
しかし自分は最後まで実態のよく分からない、プログラムとか？みたいな印象で読み進めていました。

この定義は1章に書かれていたようでした。

プログラム用APIとしてのWeb
最後に、API(Application Programming Interface)としてのWebがあります。
ユーザインタフェースとしてのWebは人間向けのインタフェースでしたが、APIとしてのWebはプログラム向けのインタフェースです。
APIはプログラム用のインタフェースですので、データフォーマットにはXML(Extensible Markup Language)やJジェイソンSON(JavaScript Object Notation)など、プログラムで解釈・処理しやすいものを用います。
APIとしてのWebは「Webサービス」(Web Service)とも呼ばれますが、この言葉はWebで提供するサービスやサイトを指すときにも使われます。
たとえばブログサービスやソーシャルブックマークサービスを「Webサービス」と呼ぶことがあります。
紛らわしいので以降本書では、特に断りのない限りプログラム向けのインタフェースを指すときは「Web API」という言葉を使います。
「Webサービス」という言葉は、Webで提供するサービスやサイトを示すときに使います。

APIとしてWebを使う、つまりプログラムを用いてWebを操作する？ことを指しているのですね。
個人的にはもっと具体的にどのような活用方法があるのかなどを書いてくれると具体性があって利用用途が想像しやすかったと思います。

Atom

こちらの単語も定義がよく分からないまま度々登場していました。

12章でまるまる書かれてはいるのですが、15章でも簡略的に説明されていました。

Atomはブログや検索結果、ポッドキャストなどのリスト情報を表現するのに向いているフォーマットである。
目的に応じて多様な拡張が存在することも大きな特長。
しかし、ID(<id>要素)、タイトル(<title>要素)、著者(<author>要素)、更新日時(<updated>要素)が必須なので、著者や更新日時を持たないデータには適用しづらい

いいですね、もう少し丁寧に利点などが書かれていればもっと序盤で登場していても良かったと思います。

WebDAV

こちらはついぞ説明はありませんでした。
おそらくWeb機能の拡張機能みたいなものかな？みたいな印象でした。

それでいて本文では以下のように書かれていました。

▶207 Multi-Status ── 複数の結果を表現する
ただし、207 MultistatusはWebDAV仕様に強く結び付いたステータスコードのため、今回くらいの処理へのレスポンスにはオーバースペックだとも感じられるでしょう。

WebDAVがどういう機能か、どんなハードルがあるのか分からない中で上のように言われてもピンときませんでした。(WebDAV自体というより、レスポンスのXMLのことを指していたのかもしれませんが)

WebDAVはWeb Distributed Authoring and Versioningの略で、「サーバ上のファイル編集やファイル削除等を簡単に（FTPを利用せずに）処理できるようにした仕組み・技術のこと」のように解説されています。
他にも排他制御、ロック機能が備わっており本書ではそちらが解説されています。

そう考えると207レスポンスを使うためだけに使用するのはオーバースペックかもしれませんね。

Ajax

こちらはたまに見かける程度でしたが、自分は偶然知っていたので理解することができました。

一応2章でAjax(Asynchronous JavaScript and XML)とあったのですが、それで全容が分かるわけでもありません。
JSONについての説明で以下のように言われてもピンとこないでしょう。

Webサービスでは、ブラウザがJavaScriptを実行できるので相性が良いこと、XMLと比べてデータ表現の冗長性が低いことなどの利点から、Ajax通信におけるデータフォーマットとして活用されています。

AjaxとはJavaScriptとXMLを使って非同期にサーバとの間の通信を行う技術のことで、GoogleMapのようにWebページ上で操作して様々な情報が表示できます。
非同期についてですが、まず同期処理は一瞬画面が白くなって、画面を切り替わることを言い、その点非同期は画面が切り替わることなく情報を更新できることを言います。

このことを知っていると、XMLよりデータ表現の冗長性が低いことの利点が見えてくるでしょう。(転送するデータ量が少なくて済むなど)

本書の構成について

2章

1章ではWeb技術の基本的な解説があり、続いて2章ではこれまでのインターネット技術について解説されていました。
正直1章を読んだ後なので早くHTMLやHTTP、URIについて知りたい！と思っていました。

おそらく著者が言いたかったことは、様々な経緯があり、その中で選ばれたRESTはどういう点で優れていたのかというのを伝えたかったのでしょう。
ですが初期の技術から順に語っているため文量が多くなっています。
なので要点さえ押さえていればこの章を読むのは後回しにしても良いのかなとは思いました。

RESTの利点はシンプルであること、これが言いたかったのだろうと思います。
その点が分かっていればRESTの構成がどうしてこのようになっているのかなどが感じられると思います。
(それを実感するためにもこの文量なのかもしれませんが)

第5部(15,16,17章)

こちらは構成というより、ただ単に難しくて大変だった箇所です。
これまで学んできたHTTPのヘッダやHTMLのタグなど、すべての知識が詰まっています。

詰まっている分解説しきれてない点や以前書いたが覚えれてない点も多く、読むのは大変でした。
例えば、ETagについてはどのような値ならそんなことができるんだ？と悩んでいたのですが、よくよく読んでみたら9章に書いてありました。
またHTMLを書いている箇所ではプログラムだけしか載っておらず外観が想像できませんでした。

これは紙面の量的に仕方ないことだと思いますが、もう少し丁寧なチュートリアルをやった方が身につくかもしれません。
ある程度分かるようになった人が読めば「こういう実装が良いよな」と共感できるのかもしれませんね。

気になった点

2章：Web以前のハイパーメディアの課題

概要
Web以前のハイパーメディア（Memex, Xanadu, HyperCardなど）は、複雑なリンク機構（双方向リンクなど）を採用したため、普及が難しかった。
Webが成功した理由（シンプルな単方向リンクの採用）を理解する上で重要。
疑問
なぜ双方向リンクだと難しいのか？
そもそも双方向とは何か？
回答
双方向リンク（Web以前のリンク）：リンク元とリンク先の両方が、お互いにリンク情報を保持・認識する仕組みです。例えば、文書Aから文書Bへリンクを張るとき、文書Aだけでなく、文書Bも「文書Aからリンクされている」という情報を保持します。
難しさの理由：文書Bが文書Aの情報を保持したり、リンク切れを防ぐためにリンク元（文書A）の変更を監視したりする必要が生じ、システム全体（特にサーバー側）の管理と実装が非常に複雑になります。
疑問
じゃあ双方向リンクが必要だと考えていた人たちは、情報の正確性を求めていたってこと？
回答
はい、その理解で正しいです。
Web以前のハイパーメディア（MemexやXanaduなど）を推進していた人々が双方向リンクにこだわった主な理由は、情報の「完全な管理」と「健全性」をシステム側で保証しようとした点にあります。
これは、現代でいう「情報の正確性」や「信頼性」を技術的に追求した結果と言えます。
疑問
クライアント/サーバー以外の通信
回答
Webの基本的な通信は、クライアント（ブラウザなど）がサーバーにリクエストを送り、サーバーがレスポンスを返す「クライアント/サーバー」（リクエスト/レスポンス）型です。
本書の範囲内で、これ以外の通信形態として言及されているものには、以下があります。
P2P（Peer to Peer）
メールプロトコル
RPC（Remote Procedure Call）

4章：相対URIの必要性

疑問
相対URIやベースURIは必要なのか？
絶対URIが分かっていればいいのでは
回答
以下のような利便性から広く使われます。
簡潔さ: 相対URIは文字数が少なく、記述が簡単です。
柔軟性: URIのホスト名やスキーム（http や https など）が変わっても、リソース内部のリンクを修正する必要がありません。

URIの修正が最小限になるという利点は大きいですね。

14章：scriptタグのセキュリティ

概要
Ajaxで用いるXMLHttpRequestというJavaScriptのモジュールは、セキュリティ上の制限からJavaScriptファイルを取得したのと同じサーバとしか通信できません。
JavaScriptがあるサーバとは別のサーバと通信できてしまうと、ブラウザで入力した情報をユーザが知らない間に不正なサーバに送信できてしまうからです。
XMLHttpRequestではクロスドメイン通信ができませんが、実は代替手段があります。
HTML の <script> 要素を用いると、複数のサイトからJavaScriptファイルを読み込めるのです。
疑問
scriptタグならできる理由は？
セキュリティ的な問題を解決する方法はないのでは？
回答
できる理由: <script> タグは歴史的に外部ファイルの実行が許可されている（Same-Origin Policyの例外）。
セキュリティ: 非常に危険です。 相手のサーバーが悪意のあるコードを返すと防ぐ手立てがありません。
結論: 現在は <script> を使ったデータ通信（JSONP）は避け、標準的な CORS を使うのが正解です。

16章：トランザクションの確約

概要
▶トランザクションリソースの削除
これで、このトランザクションは完了です。
http://zip.ricollab.jp/1、/2、/3すべてのリソースを削除しました。
疑問
なぜ成功が確約されているのか？
リソースをひとまとめにしただけではないのか？
回答
これは、まずトランザクションの開始時に専用のトランザクションリソースを作成し、そこに処理対象のURIを追加（PUT）します。
そして、トランザクションリソースにコミットを伝えるデータ（例：commit=true）をPUTで書き込むことで、トランザクションを実行します。
実行が成功すれば200 OKが返り、失敗すれば4xxか5xxのステータスコードが返されます。失敗した場合、どちらも削除しないことが保証されます。