Zenn
📖

Webを人に教えられないので「Webを支える技術」を読んでみた

2024/05/04に公開
技術書
読書
idea

https://gihyo.jp/book/2010/978-4-7741-4204-3

はじめに

なんとなく使っているWeb(というかHTTP)を順序立てて説明できるようになる目的でこの本を読みました。
自分の理解との齟齬を中心に感想を書いていきます。

読んだモチベーション

普段の開発でWebAPIを使用・実装していますが、この時のHTTP通信はプログラミング言語の標準機能(またはライブラリ/フレークワーク)で抽象化されています。
自分であればJavaのServlet、 JavaScriptのFetch APIがそれに当たります。
ライブラリが綺麗に抽象化してくれているので詳細は分からなくても割と困らずに開発ができてしまいます。(仮に何か作業が必要だったとしても、WebAPIの実装をする頃には整備された状態になっていると思います)

知識の不足は開発する時にはなんとかできますが初学者に教えるときに困ります。
0 から教えることが難しいです。

教えることを考えた時に現れた疑問たち

  • HTTPのリクエスト/レスポンスからRESTまで拡張していくのか？
  • RESTからHTTPの詳細を深掘りしていくのか？
  • URLの構成要素とかCookieってどのタイミング？
  • HTTPヘッダってどこまで教える？

そういう理由で基本を押さえておこうと考え、この本を購入しました。

感想

2010年初版であり2024年現在では古い内容がいくつかありましたが、概ね知りたかったことが書かれていたので満足のいく内容でした。

  • Webを説明していく順序
  • HTTP、URL、REST の説明の粒度

以降はセクションごとに感想を書いていきます。

第1部　Web概論

単純なクライアント/サーバー構成に5つのアーキテクチャスタイルを追加していきREST(Uniform Layered Code on Demand Client Cache Stateless Server)に至るまでの流れが解説されています。
Client Server -> Client Stateless Server -> ... -> REST
他にも、インターネットの誕生からRESTが普及するまでの歴史が解説されています。

「なんとなくRESTってこうだよね」といった感覚的な理解を持っていてRESTの構成要素を分解する発想がなかったので非常に勉強になりました。
要素ごとに分けて考えると他人に解説する時にもどういう特徴を持っているのかも伝えやすいですね。

第2部　URI

前半(第4章　URIの仕様)では文字通りRFC3986に基づいたURIの解説がされています。(URIスキーム、ホスト、パス、 etc...)
後半(第5章　URIの設計)はURIはリソースを表現する名詞にする(この本の引用) を具体的にどう実現するのかについて書かれています。

大体の内容はそういうURIを見たことあるし実装したこともあるので直感に一致していると感じましたが、マトリックスURIは初耳でした。
/区切りではリソースの階層構造しか表現できないので緯度軽度のようなものを扱うときにマトリックスURIを利用します。
実際に、Google Mapでは使用されていることを確認しましたが、マトリックスURIをGoogleで検索してもこの本の記事ばかりが見つかりますね。(あまり一般的ではないのだろうか?)
気になってもう少し調べてみましたがRFC3986のPathセクションに記載があり、name;v=1.1、name,1.1といったように使い方も例示されていました。
ただ、この使い方だとnameというリソースを修飾する形でv=1.1をあてがっているように見えますね。

第3部　HTTP

クライアント/サーバー間の通信やHTTPメソッド/ステータスコード/HTTPヘッダについて解説されています。
もちろん2010年時点なのでHTTP1.1についてです。

開発している時にはHTTPリクエスト/HTTPレスポンスは抽象化されていてペイロード/ステータスコード/レスポンスボディくらいしか意識しないことが多いので、この本を読むに当たって一番興味のあったところです。

他のHTTPメソッドでは表現できない操作にはPOSTを使用するというのは意外でした。
言われてみれば、WebAPIを設計するときに意味的にはGETなのだけどPOSTにしてリクエストボディを使いたくなる時はありますね。
他にも、GraphQLもPOSTを使用していますね。

HTTPヘッダではキャッシュの説明が多く、この知識はなかったので勉強になりました。
普段の開発ではRDBからデータを取ってきてWebAPIのレスポンスを作っているのでキャッシュすることがないのですよね。
個々人の状況でかなり変わると思いますが、変更があるかどうか調べるためにSQLを発行する必要がありますし無理してキャッシュ用のレスポンスに変えるほどでもない判断をしています。
(完全な妄想ですが... RDBとは別にキャッシュ用のNoSQLデータベースを使うようなシステムならキャッシュ関連のHTTPヘッダと組み合わせることもあるかもしれませんね)

第4部　ハイパーメディアフォーマット

レスポンスボディで使用されるHTML/microformats/Atom/JSONについて解説されています。
時代の影響をもろに受けている内容なので流し見しかしていません。
特に感想はないのですが、microformatsというのを始めて知りました。

第5部　Webサービスの設計

第15章　読み取り専用のWebサービスの設計と第16章　書き込み可能なWebサービスの設計に分けて、要件に対してどういったリソースを定義し、HTTPメソッドとURIに落とし込んでいくか解説されています。
第17章　リソースの設計ではさらに細かくリソースを定義するアプローチが解説されています。

郵便番号検索サービスを題材にWebAPIの例を示していますが、自分のリソースの感覚と異なっていました。
まず、この本で登場したURIを抜粋します。

  • 郵便番号リソースの例 http://zip.ricollab.jp/1120002
  • 地域リソースの例 http://zip.ricollab.jp/東京都/文京区
  • 検索結果リソースの例 http://zip.ricollab.jp/search?q=小石川

自分がURIを設計する時にはフォルダ階層をイメージします。
無秩序なフォルダ階層ではなく同じ階層ではルールが統一されるようにします。

例えば

  • 郵便番号リソースなら http://zip.ricollab.jp/zip_code/1120002
  • 地域リソースならhttp://zip.ricollab.jp/region/東京都/文京区
  • 検索結果リソースなら
    • http://zip.ricollab.jp/zip_code?q=
    • http://zip.ricollab.jp/region?q=

のように、以降のパスでどういう種類を指定するのかがわかるようにします。検索にはクエリを使います。

どちらがいいということではなく、自分の分け方はSpringBootでWebAPIを実装しやすくすることを念頭に置いているものなので、この本の具体例のように本来のリソースはもっと自由なものだということを感じられました。

具体的に何をリソースとするべきかには三つの方法が述べられています。

  • 関係モデル
    • この名前だとピンと来なかったのですがRDBでテーブル設計をする時に使う方法
  • オブジェクト指向モデル
  • 情報アーキテクチャ
    • 個人的には情報設計という方が聞き馴染みがあります

WebAPIはサーバサイドエンジニアが中心になって設計すると思うので、自ずとテーブル設計と同じ方法を使うことになりそうですね。
自分もテーブル定義に引っ張られてWebAPIを設計することが多いです。

情報アーキテクチャはデザイン寄りのエンジニア/デザイナーが行う印象があります。
ブラウザで表示するためのURIはこちらの考えで作った方がクールなURIになりそうですね。

付録

  • 付録A　ステータスコード一覧
  • 付録B　HTTPヘッダ一覧
  • 付録C　解説付き参考文献

が掲載されていました。

終わりに

何も知らない概念の本を読むわけではないのでサクサク読めるかと思いましたが、自分の認識との違いやそもそも知らないことがあり、意外と時間がかかりました。
今回は他人に教えるにはどうしたらいいのかを考えて本を読み始めましたがもう少し定期的に技術書を読んだ方がいいですね。

Discussion