«前の日記(2010-04-06 (火)) 最新 次の日記(2010-04-17 (土))»  

まちゅダイアリー


2010-04-16 (金)

Webを支える技術 - なぜ今「HTTP, URI, HTML」か

話題になっている「Webを支える技術」を買って読んでいる。

「いまさらHTTPの本かぁ」と思った人にこそ、この本はオススメ。 HTTP は新しいプロトコルや技術じゃないし、これだけ当たり前に普及しているものを、なんで今さら深く知る必要があるのか。

GET, POST, Cookieだけを知っていればいい…時代もあった

10年くらい前にWebアプリが登場しだしたころは、GETとPOSTの違いとか、Cookieの使い方を知っていれば、とりあえずWebアプリを書くことはできた。 正しいHTTPの使い方なんて、一部のマニアにしか興味がなく、「クライアントアプリを配布しなくていい」、「(HTTPしか許可していない)ファイアウォールを越えられる」ことがHTTPをベースとしたWebアプリの強みだった。 HTTPと言えば、「GETだと大きなデータを送れないからPOSTを使う」とか、「GETを使うとアドレスバーにデータが表示されるから危険」くらいの感覚。

HTTPレイヤの知識は重要ではなく、極端に言えばHTTPはただの伝送プロトコルだった。 本来HTTPが持っているメソッド(GET/POST/PUT/DELETE…)や、ステータスコード(200, 302, 500)は十分に活用されず、その役割は上位でやりとりされるHTMLが担っていた。

HTTPの誤用による弊害

例えば、

  • POSTの乱用
  • METAタグによるリダイレクト
  • ステータスコード200で返されるエラー画面
  • ステータスコード200で返される移転のお知らせ画面

などなど。

それでも、これまでは困らなかったんだよね。 その理由は、Webを使うのがWebブラウザの向こうにいる人間だったから。 人間にとっては、Webブラウザ上に表示される文字や絵がすべてであり、それがどうやって送受信されているかなんてどうでもよかった。

ところが、「HTTPをただの伝送プロトコルとして使う」という考え方は、徐々に弊害がでてくる。 たとえばRSS/フィード。 ブログを移転したときに、「このブログは○○へ移転します。お手数ですがRSSを再登録してください」というフィードを流して、利用者に手動で登録変更してもらう例をよく見かけた。 RSSリーダーによっては、ステータスコード301を返せば自動的に移転先のRSSを登録するようになっているのに。

HTTPがただの伝送プロトコルになろうとしていた時代から、何が変わったのか。 それは、人間だけでなく、コンピュータもWebを使うようになってきたこと。

HTTPはWebAPI/Ajax時代の一般教養

これまでは人間がWebブラウザを使ってHTMLを見るだけだった。なので、エラーメッセージはHTMLに書けば良かった。 でも、先ほどの例のRSSをはじめ、WebAPIやAjaxの普及によって人間だけでなくコンピュータ(様々なWebクライアント)もWebを使うようになった。 コンピュータはHTMLに書かれたエラーメッセージは理解できないので、正しくHTTPを使ってコンピュータにも理解できるようにしてあげなければいけない*1

コンピュータにも理解できるようなWebの世界とは何か。 ここで重要になるのが、RESTという考え方(アーキテクチャスタイル)と、それを具現化したHTTP, URI, HTMLというアーキテクチャ。 分かりやすく言うと、HTTPは元々コンピュータにも理解できるように作られているので、HTTPをHTTPらしくシンプルに使えばいいということ。

「Webを支える技術」がいま重要な理由

ようやく本書の話に辿り着いたけど、本書の価値は「HTTPをHTTPらしくシンプルに使う」ための考え方を身につけられることにある。 以下、前書きから引用。

簡単に接続するWebサービスと、接続するのが難しいWebサービスとの違いはどこにあるのでしょうか。 その答えは「Webらしい設計にある」、と筆者は考えています。サービスをWebらしく作ると、ほかのシステムと簡単に連携でき、将来の拡張も楽になるのです。 良い設計のWebサービスは、Web全体のアーキテクチャと調和しています。Webらしい良い設計をするためには、Webのアーキテクチャを理解して意識することが大切です。

Webを支えるHTTP, URI, HTMLに関する情報は、ネットでもいくらでも見つけることができる。 でも、仕様だけでなくその背景にある考え方まで踏み込んである情報は少ない。 「Webを支える技術」は、Web本来の使い方について書かれた貴重な本。 この本を読んで考え方を理解することで、Webアプリ/Webサービスを設計するときの指針を身につけることができる。

例えば、HTTPにはGET/POST/PUT/DELETEなどのメソッドがあることを知っている人は多いけど、それぞれのメソッドは「べき等性」と「安全性」によって分類できるということまで知っている人は少ないと思う*2)。 こういう概念を知ると、POSTした画面をリロードするときにダイアログが表示される理由が分かるようになる。

この本の良いところは理論だけでなく、現実的な話も書かれているところ。 例えば、通常のWebブラウザでは、どのようにPUTやDELETEなどのメソッドを代用するかなど。 後半では、実際にWebサービスを設計する場合のチュートリアルも含まれている。

一方で、まったくの初心者には少し敷居が高いかもしれない。 たとえば、Webアプリを作る上で必須となるCookieについては、さらりとしか触れられていない。

まぁ、この日記をここまで読んでくれる人には、自信を持ってオススメできる。

終わりに

JavaScriptが初期に誤解され、それから本来の価値が見直されたように、HTTPもここ数年でその役割が見直されるようになってきたといえる。 HTML5などとは違って新しい技術/プロトコルじゃないけれど、だからこそ基礎をしっかり理解しておくことが大切。

馴染みの薄い人には、この本と一緒に Ruby on Rails を使って簡単なアプリを作ってみると、より理解が深まると思う。 ある程度慣れている人には、microformatsや Atom, AtomPP などの新しめの話題に触れた章がオススメ。 5月の連休のお供にどうでしょう。

追記

あわせて読みたい。【書評】Webを支える技術 - GoTheDistance

Tags: Book

*1 HTTPをただの伝送プロトコルとして使って、上位のXMLにエラーメッセージを含めるSOAPもあるけど、ここでは割愛。Webを支える技術ではSOAP vs RESTについても触れられている

*2 僕もこの本の元となったWEB+DB PRESSの連載を読むまでは、GETは何度繰り返しても安全だけどPOSTはそうじゃないという程度の認識だった

本日のツッコミ(全1件) [ツッコミを入れる]
Chiether (2010-04-23 (金) 02:55)

当時…いや今もですが。ことさら当時は、<br>一番何もできないヤツを、意識した開発が主流でした。<br><br>>RSSリーダーによっては、ステータスコード301を返せば自動的に移転先のRSSを登録するようになっているのに<br><br>の例であれば。<br>301を理解できないRSSが利用されている可能性が無視できないのであれば<br>「301で処理しない」と仕様が決まるわけです。B2Cでは、ことさら意識するところです。<br>(現実的な要求としては、両方フォローしろと言われるのでしょうが)<br><br>これがHTTPではなく悪名高いSMTPならどうでしょう?<br>ReferencesヘッダやKeywordsヘッダ(RFC822)、Sensivityヘッダ(RFC1327)があります。<br>これらは、私たちが使っている一般的なクライアントで何かしらの動作をします。<br>もちろん「無視する」クライアントも同じように存在します。<br>でも。これらヘッダ情報に、依存するようなサービスやコンテンツは、提供したいと思わないでしょう。<br>事実。BCCヘッダを記述した場合の動作ですら危ないものです。<br>(ヘッダもコンテンツの一部なのに、SMTPサーバが書き換える可能性が結構あります)<br>なぜならばSTMPが担うのは"MAILFROM"や"RCPT"や"BODY"であって"FROM:"や"TO:"、"CC:"、"BCC:"、"SUBJECT:"でないからです。<br><br>もちろん「知ってるけど使わない」のと「知らないから使えない」のとは大きな違いがあります。<br>振舞うべきことが定義されている以上は、何かしらの意図があって、存在しています。<br>それらを、知ることで造詣が深まることは、私も大切なことだと思います。<br>個人的には、さらに「プロトコルの層」を意識できるといいなと。たとえば、HTTPとHTMLはプロトコル層が違うんだぞと。<br>頭の片隅にでも意識できるよう期待します。(といっても。私も層の意識を、忘れがちですが...)