プロになるためのWeb技術入門

［改訂新版］プロになるためのWeb技術入門 | 技術評論社

なぜWebシステムをうまく作ることができないのか？――本書は2010年に初版が発行されました。Webに携わるエンジニアだけでなく、Webマーケティング担当者にいたるまでWebの仕組みを根本から理解するための技術書として多くの方々に利用されました。それから10数年の月日が流れ、本書の特徴である技術の根本をていねいに解説するスタイルはそのままにアップデートを図りました。最新のWeb技術を取り入れて全面改訂です。さらに技術を学ぶ上でのさまざまな悩みを解消し、エンジニアとして成長していく手がかりをふんだんに盛り込みました。もちろんサンプルアプリケーションプログラムを試しながら理解を深めていく工夫もしています。本書によって本質をとらえるプロの技術力も得てください。

https://gihyo.jp/book/2024/978-4-297-14571-2

2025-10 からSREの仕事を半分以上減らして、webdevを兼務し始めました。Webアプリケーションの開発をするのは、約4年ぶりだったため¹、改めてそれらの技術領域を概観できるような書籍を求めていました。
大きめの図書館に足を伸ばした時に、この書籍を友人におすすめしてもらい、購入に至りました。

この書籍の第一章では、技術を「点」の理解から「線」に、「線」から「面」に、そして「面」から「立体」の理解にしていくことが、効率よく技術を学ぶためのポイントであると指摘しています。それぞれは、歴史を知ること、関係性を知ること、階層としてとらえることを通して達成されます。

読了後に、私は今自分が扱っている技術、扱っていた技術に関して、一定の相対化ができたように思います。相対化なしでは、意思決定に際し、トレードオフを吟味することは出来ないでしょう。仕事をするうえで読んでおいて良かったと思う機会がすぐに来そうです。あるいは、自覚はないだけで既に役立っているかもしれません。

ブックガイドとしても、非常に優秀そうです。
QUICのことが気になったものの、手元のReal World HTTPがやや古いのでQUICがちらっとしか載っていないことに気づきました。第三版買おうかな。

ちなみに、サンプルコードが Go だったので、Go に馴染みのある私にとっては読みやすかったです。

ぼんやりと理解していた概念たちの輪郭がはっきりした

「Web API とは一体なにか？」と問われたら、「httpによってネットワーク越しに呼び出せるAPI」と返します。すかさず「具体的には何が含まれる？」と聞かれたら、…きっと私は黙り込んでしまっていたことでしょう。
はっきりとした定義はなく、文脈によって異なると書籍の中でも指摘されていますが、整理された図が P. 325 にあります。分かりやすい。これが絶対の解ではない可能性はありますが、少なくともこれをベースに認識を積み重ねることができそうです。

多くのケースにおいて、WEB API は REST風API（RESTish API）を指すそうです（≒ Restful APIの上位集合）。REST風 も Restful も どちらも発音が似ているのが個人的にはクスッと来るポイントです。RESTを提唱したFieldingさんはRESTの厳密さにおいては苛烈であるため、笑い事ではないのかもしれません ²

文字コードに関してもそうです。私の中で、「符号化文字集合」と「文字符号化形式」がごっちゃになっていることに気づくことができました。ASCIIにおいてはこの区別が不要なので混乱してしまったように思います。
「符号化文字集合」は、文字集合のひとつひとつの文字に対して、識別用に数値を割り振ったものです。この数値のことをコードポイントと呼びます。Unicode や JIS X 0208 が「符号化文字集合」に当てはまります。
一方で、「文字符号化形式」はテキストデータの保存や交換用に、コードポイントを少し変更した形で表現したものです。コードポイントをそのまま32ビットに格納した UTF-32 はあまり使われず、ASCIIとの互換性をもたせた UTF-8 が広く利用されています。JIS X 0208 に対応するものであれば、Shift_JIS や EUC-JP が 「文字符号化形式」にあたります。

この本に目を通し、今まで曖昧に理解していたことに気づき、輪郭がはっきり見えてきたものとして、他にも以下のような項目がありました。

• Webアプリケーションの実行方式（P. 25）※ 著者の命名ですが頭の中の整理に役立ちました
  • プロセス起動方式: CGI
  • モジュール方式: apache の mod_ruby や nginx_mruby など
  • 分離型独立プロセス方式: apache -- ajp --> tomcat など（静的ファイルの配信はapacheがやる）
  • 一体型独立プロセス方式: Node.js や Spring Boot, Go
  • アプリケーションサーバ方式: Glassfish や Websphere を利用して、複数のwarを一つのサーバにデプロイして動かす（docker普及でかなり減った）
• jQueryが重宝されていた理由（P.258）
  • 当時は大きかったブラウザ間の差異を吸収してくれた
  • FetchAPI以前のXHR全盛時代の非同期通信を簡単にしてくれた
• XMLHttpRequest （XHR）と XML との関係性（P.265）
  • 特別な結びつきはない
  • 1999年（1999年 !?）にブラウザ版Outlookのために、急遽IEのXML用ライブラリに潜り込ませてリリースしたかららしい
• Web API における新規作成時の POST と PUT の違い （P. 341）
  • POST の場合はリソースの名称をサーバが決めて、ステータスコード 201 Created とともに Location ヘッダにURLを返す
  • PUT は更新のみならず、作成するリソースの名称をクライアント側で決める場合の新規作成時にも利用される
• プリフライトリクエストの有無（P. 368）
  • Cross Origin 通信では、ブラウザがサーバにOPTIONメソッドによるHTTPリクエストを送ることが知られているが、ざっくり「GETやHEADなどのサーバ側に影響を及ばさない安全なメソッド」あるいは「HTMLフォームが送信できる範囲のPOSTリクエスト」では、プリフライトリクエストは飛ばない

wwwの始まりとその設計思想をWeb APIに応用したRestful API

素粒子物理学の一大研究拠点である ³ CERNに所属していたティム・バーナーズ・リーの個人プロジェクトに端を発したWorld Wide Webの優れていた点は、URI / HTTP / HTML の仕様を中心に据えたことだったようです。それらを実装するWebブラウザやWebサーバのソフトウェアも開発していましたが、仕様を中心にすることでユーザ増加と発展に繋がったと指摘しています。
この3つの仕様が同時期、更に同一人物によって生み出されていたことには驚きました。このプロポーザルが執筆されたのが1989年…平成元年です。wwwが産声を上げてからまだそう時間は経っていないことに驚きました。
彼の目的は、「世界中にいる先端研究者が論文や研究成果を共有して共同研究を進める」ことだったと書籍「インターネット文明」は指摘していますが、35年ほどでここまで用途が広がることをティム・バーナーズ・リーは果たして予想していたのでしょうか。

彼は URI / HTTP / HTML を既存技術の延長と主張することで（実際にそう）、理解や導入の敷居を下げていたようです。本書内でも言及されていますが、これは様々な場面で応用が効きそうです。

長く使われる技術は、当初の設計思想を超える使われ方をすることがあると本書は指摘しています。HTTPとHTMLはインターネット上の情報交換をするための手段として生み出されたものでした。換言すると静的コンテンツがWebサイトの主体でした。
1993年あたりに起こった、HTMLへのform要素の追加とCGIの登場により、Webサイトの主体が動的コンテンツに移っていきました。アプリケーションのUIとして活用されるようになったのです。
HTTPはステートレスなプロトコルであり、アプリケーションで必要とされるセッションを独自に実現する必要が出てきたりしました。
更に、SPAの登場により、Webにおけるサーバサイドの役割は「要求された処理の実行」に変化していきました。つまりWeb APIです。

Web APIの設計に一つの指針を示したのが、RESTです。このRESTをWeb APIに当てはめて具体化したものをROA（Resource-Oriented Architecture）と呼ぶわけですが、これには4つの特性があります。アドレス可能性、接続性、統一インターフェース、ステートレス性です。
著者は「この4つの特性はティム・バーナーズ・リーが考えた当初のWebの思想を、Web上のAPIに当てはめましょうということ」という理解を示していることです。
ここにきて、wwwの考え方に戻ってくるのかと非常に面白く感じたポイントです。
RESTがカバーしきれない部分を埋めようとしているGraphQL（PRCスタイル）が普及し始めていることも含め、味わい深い流れを追うことができました。

SPAが普及するまでの経緯

SPA（Single Page Application）へとアーキテクチャが転換するきっかけとなったのは、2008年にChromeに採用されたV8だと筆者は指摘しています。
それに加えて、2005年頃に登場したGmailやGoogle Mapsの高い操作性を実現したAjaxがブレイクスルーであったと言及されています。
パフォーマンスの飛躍と既存のweb標準技術の効果的な組み合わせという両面が重要だったのですね。

初期SPAが抱えた課題の解決が特に面白かったです。フラグメントによるページ表現が抱える負の面はHistory APIで解決したわけですが、このHisotry APIがHTML5から登場したAPIであることは知りませんでした。ルータの簡易実装に関する一定の紙幅を割いての説明やサーバサイドレンダリングに関する説明は、今業務で触っている技術（React + Tanstack Router）に直結するもので興味深く読むことができました。