はじめに
よくオススメされている「Webを支える技術」を読んだので、読みながら自分で調べたことも補記しつつ、読書録としてまとめる。
「Web技術の基本」という本はエンジニアになる前に読み、「Webを支える技術」も次に読もうと思っていたのだが、日々業務を行ったり基本情報の勉強をするうちに「大体わかった」気になって後回しになっていた。
だが当たり前に理解していないといけないことを、きっちり当たり前に理解したいと思い、遂にこの本を読んだ。
本書の目的
Webサービスは、「Webらしい設計」ができていると他のシステムと簡単に連携でき、将来の拡張も楽になる。
良い設計のWebサービスは、Web全体のアーキテクチャと調和している。
Webらしい良い設計をするためには、Webのアーキテクチャを理解して意識することが大切であり、本書はWebサービスをいかにWebらしく設計するかをテーマとしている。
Webを支える技術
結論、Webを支える最も基本的な技術は以下の3つ。
- URI
- HTTP
- HTML
HTTP, URI, HTMLに支えられたWebは、情報システムとして見るとハイパーメディアシステムと分散システムの2つの側面を持っている。
ハイパーメディア
ハイパーメディア以前のメディア（書籍や映画など）では、先頭から順に読んだり視聴したりするのに対し、ハイパーメディアではユーザはある情報から別の情報へと自由に参照できるようになる。
分散システム
複数のコンピュータをネットワーク上に分散して配置し、1台のコンピュータで実行するよりも効率的に処理するようにしたシステム。
Webは世界中に配置されたサーバーに世界中のブラウザがアクセスする分散システム。
分散システムとしてのWebが特徴的なのは、プロトコルがシンプルな点。
RESTとは
Webが急速に普及する中で、各社の実装がバラバラであるために相互運用性に欠ける状態が発生し、Webの標準化の必要が出てきた。
このweb標準化のために様々な設計思想が提案され論争が起きたが、その中で現在最も普及したのがRESTだった。
つまりRESTはwebの設計思想であり、アーキテクチャスタイルである。
アーキテクチャスタイルから抽象度をひとつ下げたものがアーキテクチャで、アーキテクチャにはブラウザ、サーバ、HTTP、HTMLなどがある。
これらを使ってWebを設計しようというのが、RESTが意味するところ。
リソース・アドレス可能性
RESTを説明する前に、RESTにおける重要な概念のひとつであるリソースについて説明しておく。
リソースとは、「Web上に存在する、名前を持ったありとあらゆる情報」のこと。
それぞれのリソースは一意のURIを持ち、このURIを用いることでプログラムはリソースが表現する情報にアクセスできる。
このURIが持つ、リソースを簡単に指し示せる性質のことをアドレス可能性と呼ぶ。
今でこそURIは当たり前になったが、WebとURIの発明以前は、ファイルをどこかのサーバに置いてその場所を誰かに伝える場合、
- ドメイン
- ディレクトリ
- ファイル名
- プロトコルやログインユーザ
といった情報を、下記のように自然言語で詳しく説明する必要があった。
From:yohei@example.jp
To:inao@example.jp
Subject:SampleFileお疲れさまです。
先日聞かれた例のファイルをftp.example.jpに置きました。
ディレクトリは/public/dataで、ファイル名はsample_file.gzです。
このサーバはanonymousFTPなので、匿名ユーザでログインしてください。
引用：山本 陽平. Webを支える技術 HTTP，URI，HTML，そしてREST （p.81）
これらを記した文章を人間が解釈するのはまだ簡単だが、プログラムで解釈するのは至難の業であり、URIはこの問題を一気に解決した。
URIは構造を持っている為、プログラムで簡単に処理できる。
アドレス可能性という言葉は知っていたが、URIが発明される以前の具体例を読んでURIのすごさが初めて実感できた。
※URIについて、詳しくは次の記事にて。
RESTの構成
RESTは「クライアント/ サーバ」にいくつかの制約を課して構成されており、いくつかのアーキテクチャスタイルを組み合わせて構築されたもの。
具体的には、RESTは「クライアント/ サーバ」に次の5つを組み合わせたアーキテクチャスタイルである。
• ステートレスサーバ
• キャッシュ
• 統一インターフェース
• 階層化システム
• コードオンデマンド
クライアント/サーバ
Webは、HTTPというプロトコルでクライアントとサーバが通信するクライアント/サーバのアーキテクチャスタイルを採用している。
クライアントはサーバにリクエストを送り、サーバはそれに対してレスポンスを返す。
クライアントとサーバで処理を分離することで、
- PCだけでなくスマホやゲーム機からもWebにアクセスできる
- ユーザインタフェースはクライアントが担当する為、サーバはデータストレージとしての機能だけを提供すればよくなる
- 複数のサーバを組み合わせて冗長化することで、可用性を上げられる
といった利点がある。
Webの開発をしているとクライアント/サーバが当たり前でその利点について特段意識したことがなかったので、なるほどと思った。
ステートレスサーバ
ここでのステートレスとは、クライアントのアプリケーション状態をサーバで管理しないことを意味する。
サーバがアプリケーション状態を持たないことの利点は、サーバ側の実装を簡略化できること。
もしステートフルな状態を実現しようと思うと、サーバの数が増えた時に、クライアントの状態管理を全てのサーバ間で同期しないといけなくなる。
しかし現実には状態を管理する必要がある場面はあり、HTTPをステートフルにする代表がCookieを使ったセッション管理。
これは厳密にはRESTの視点から見ると誤った拡張だが、Cookieを使った認証が必要なことも事実なので、Cookieはステートレスサーバの利点をあえて捨てることを理解した上で必要最低限に利用しようと提唱されている。
キャッシュ
一度取得したリソースをクライアント側で使い回す方式のこと。
これにより、クライアントとサーバ間の通信量を減らすことができる。
統一インタフェース
RESTを最も特徴づけるアーキテクチャスタイル。
URIで指し示したリソースに対する操作を、統一した限定的なインタフェースで行うアーキテクチャスタイルのこと。
例えば、HTTP1.1ではGET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECTの8つのメソッドだけが使える。
たったこれだけに制限することで全体のアーキテクチャがシンプルになり、インタフェースを統一することでクライアントとサーバの実装の独立性が向上する。
Webが多様なクライアントやサーバの実装で構成されていることには、統一インタフェースが一役買っている。
階層化システム
サーバやプロキシなどの各コンポーネント間のインタフェースはHTTPで統一されている為、クライアントからするとサーアもプロキシも同じインタフェースで接続できる。
またレガシーなシステムでHTTPのインタフェースを実装していないシステムでも、レガシーシステムの前にWebアプリケーションサーバを挟んでHTTPのインタフェースを持たせることで、ブラウザなどのクライアントと接続できるようになる。
このようにシステムをいくつかの階層に分離するアーキテクチャスタイルのことを階層化システムという。
コードオンデマンド
プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するアーキテクチャスタイル。
ブラウザで動くJavaScriptなどがこれに該当する。
コードオンデマンドの利点は、クライアントを後から拡張できること。
RESTfulなWeｂサービスとは
RESTの制約に従っていてRESTらしいことをRestfulと呼ぶ。
私たちが作るWebサービスやWeb APIはWebを構成する一部なので、これらがRESTfulになると、Webは全体としてより良くなる。
さいごに
以前に読んだ「Web技術の基本」を読み直すと、RESTfulなWebサービスの性質として、
- アドレス可能性
- ステートレス性
- 持続性
- 統一インターフェース
の4つを挙げていた。
RESTの制約やRESTfulの定義は案外曖昧なのかもしれないと思ったが、要は各WebサービスがRESTの特徴に挙げられる性質を多く持っているほど、他のWebサービスとの連携を取りやすくWeb全体が使いやすくなるということだろう。
余談
この本の「はじめに」に書いてあった次の文章が、個人的にすごく印象的だった。
最初のWebブラウザと現在のWebブラウザでは実現している機能に雲泥の差がありますが、使っているプロトコルは依然としてHTTPですし、表示しているのは昔も今もHTMLです。Webが誕生してから20年、常に新しい技術が生まれてきました。しかしその基本となるアーキテクチャは同じです。これはアーキテクチャの完成度がとても高いことを示しています。
移り変わりが激しいと言われるWeb業界だが、これからもWebという普遍の土台が存在し、その上でどんどん新しい技術が生まれるんだろうな。
と思い、この文章を読んで一気に、Webをしっかり勉強したいというモチベーションが上がった☺︎