積読本だった"Webを支える技術"を読んだ感想と、本を読むための心がけ

「Webを支える技術 HTTP, URI, HTML, そしてREST」を改めて読み直した。年始に買って途中まで読んでいたものだ。

書籍 "Webを支える技術" について

本を選んだ背景と読んだ感想

書籍購入当時はスマホアプリのWeb APIを開発しており、URIの設計の参考にしたくて手にとった。 RESTという考え方やAPI設計についてとても参考になり、良い設計とは何かを知ることが出来た。

これまでは用意されたWeb APIを使う側で、URI設計について意識することがなく無意識に良くつくられたURIのAPIを使っていた。一方で設計するためにはまず利用者として当たり前だったことを言語化して理解する必要があり、その当たり前がRESTにより成り立っていることを学べた。

書籍内容と現在の状況の違い

書籍の第一版は2010年で今から10年前なので、現代と少し合わない点もある。

初版時にはHTTP/2 HTTP/3は存在しておらず、HTTP/1.1が最新であることを前提として書かれている
セマンティックWeb は2020年の今でも浸透していない
~~Web APIとして、XML、Atom / AtomPubはあまり使われなくなった~~ (追記 2020/10/4 : なんの裏付けもありません。サービスの目的によって使う/使わないがあるだけで、あまり使われなくなったというのは言い過ぎかも。XMLはあまり使われなくなりJSONが一般的になった、ということは言えるんじゃ無いかな。)

とはいえ本の本筋は2020年でもきっと多分に有用であろう。

本から学んだこと

詳細は本に譲るが、私がこの本から学んだエッセンスには例えば次のようなものがある。

1. RESTについて

REST とは今日のWebにおいて適用されているアーキテクチャパターンのことで、次の制約をもつ。

クライアント/サーバモデル
ステートレスサーバ
キャッシュ
統一インタフェース
階層化システム
コードオンデマンド

第1部第3章 p36あたりには上述のようなことが書かれている。

インターネットは、遅延が大きく、また通信相手から応答があるか保証のない分散システムである。このインターネットにおいて、端末(プログラム)(/人間) 間のインタフェースをどのように設計すべきかの原則、指針を示しているのがRESTだ。設計のときに参考になるアーキテクチャパターンとしてRESTが存在し、RESTの要素とはなんなのかを分解して解説している。

2. リソースのモデル化とURI設計

検索のような機能は、検索行為をモデル化するのではなく、検索結果をモデル化する。

Webサービス/WebAPI(以下Webサービスと呼ぶ)を設計する時、"動作"をリソースとして割り当てる(=>URIで表現する)のはよくない。 Webサービスにおける動作はCRUDであり、HTTPのメソッドであるGET/POST/PUT/DELETE で表現すべきである。

例えば検索機能は、"検索結果をGETで取得する"と表現するのが簡潔である。 Googleの検索結果のURIは https://google.com/search?q=hoge となっているが、ここで出てくるsearchは検索行為を表しているのではなく検索結果を表している。検索行為に注目してしまうと、HTTPを拡張してSearchメソッドを作ったり、検索内容をPOSTしてサーバに検索しろとクライアントに命令させたりすることになる。これはわかりづらいので良い設計といえない。

検索に限らず、リソースをモデル化するとき(すなわちそれはリソースを表現するURIになりうる)は、動作ではなく名詞で表せるものに注目すべきだ。

3. 人間とコンピュータの統一インタフェース

リソース設計の際は、WebサービスとWeb APIを分けて考えない。

良いリソースのモデル化は人間にとってもわかりやすいし、Web APIとしても使いやすくなる。なので、WebAPI用にリソースをモデル化してURIで表現し、人間にはまた別にモデル化して、、、ということは避けるべき。

積読本を読み切った感想と、本を読むスピードについて

さて、本の内容はここまでにして、以下は今回の積読消化の感想とそこから学んだことを記す。

本を読むスピードは状況や意識で大きく変わる。

1月に読んでいたときは理解できないところがあると調べて解決してから進める読み方だった。読むスピードが遅くそのまま途中で止まっていた。¹

一方、今回9月は数時間で一気に読み切った。気になったところはメモを取ることにして、読み切るために興味のわかないところ(例えばAtom/AtomPub等の項)は斜め読みにするなどして進めた。

本を読むスピードは自分の意識で変わる面がある。細かいところまで理解しながらゆっくり読み進めるか、全体を俯瞰するためにとにかく読み切ることを目標に進めるかという意識だ。また、自分の知識量に応じて変わる面もある。自分が知っていることが多く載っている本は早く読めるし、知らないことが多く載っている本は時間がかかる。さらに、自分のテンションや気分で変わる面もある。読む気があるとき、内容に興味が湧いているとき、知的好奇心から本の内容を欲しているときは、どんどんページが進んで苦なくはやく読める。

今回は一気に読み切ろうという心持ち、RESTって結局なんだっけという思いからくる知的好奇心、前回よりも知識量が増え内容の理解が進むことなど様々なことが重なったのが読み切れた要因だろう。

私は気分が乗っていないときに何も考えずに本を読むと、丁寧にゆっくり読む癖がある。他方、本の全体像をつかみ必要なところだけを読んだり、必要になったときに読み直せるようインデックスを貼る気持ちで読んだりするほうが効率が良いのではないかと感じる。実際今回の本も読み切って感じたが、後半には実例を交えたURIの設計について述べられた章があり、1月にここを読んでいれば身になるものがさらにあったはずだった。今後はどんな読み方/スピードで本を読むかを読む前に考えるようにしたい。

また、モチベーションの大切さも感じた。プログラムを書くときもそうであるし、本を読むときもそうであるが、(少なくとも私にとって)物事を進めるにはモチベーションがとても重要だと思う。モチベーションの高まっているときに躊躇なく進めることを心がけたい。 (さらには自分のモチベーションを導けるようになりたい。)

そんなこんなで積ん読を消化した勢いで他の本も読むぞ。

参考: yohei-y:weblog(著者山本陽平さんのブログ) ... この記事のURLwebteckbookはブログに記載された内容を参考にした。

追記: (2020/10/04) 不要な改行を削除

何故積ん読した当時のことを鮮明に覚えているかというと、本を読んでいた時が時間に追われながらコードを書きながら年末年始で帰省して親戚と過ごしていた映像記憶が蘇ってきたからである。エピソード記憶は強烈だ。当時はAPIの設計についても考えなければならなかったがDockerを含むインフラについても学ばねばならなかったので、のんびり本を読み切ってる場合ではない！という心情だったのだろう。 ↩