圏外からのWeb未来観測，2回目のゲストは『Webを支える技術』（⁠注1）の著者の山本陽平さんです。山本さんは，クールでロジカルな話し方をする人で，一見，典型的な理系の技術者という印象なのですが，実は，すごく激しいパッションを秘めた人でした。技術的に正しい選択を通すためには会社を辞める覚悟までしていたそうです。現代に生きる侍の一人ではないかと思います。

注1）

『Webを支える技術..HTTP，URI，HTML，そしてREST』（⁠山本陽平著／技術評論社／2010年）

『Webを支える技術』に入れなかったもの

中島：『Webを支える技術』は，もう定番の教科書としての評価が定まってますね。

山本：essaさんにもレビューしていただいて（【1】，【2】）ありがとうございます。

中島：何よりこの本は，話題の絞り込みが適切だと思うのですが，意識してカットしたところとかはあるのでしょうか？

山本：まず，プログラミング言語に依存したくなかったので，具体的な言語のコードはほとんど入っていません。その代わりHTTPの生々しいリクエストメッセージをそのまま入れる形になっています。

中島：なるほど。会社で若い人に紹介したりしているのですが，経験の浅い人にも非常に入りやすい本であるように感じます。そのあたりの配慮が良かったのかもしれませんね。

山本：長く使える定番の教科書を作ろうという狙いがありました。

中島：最初からそこは狙ってたんだ（笑⁠）⁠。

山本：はい，息の長い本を作ろうという狙いがあったので，数年で変わってしまいそうなものは省いています。HTML5もコラムで少し書いただけにしました。ほかにも，たとえばURI Templates（注2）っていう仕様を最初は入れる予定だったのですが，仕様がころころ変わって結局落ち着かないから削ったりしました。

あとはセキュリティとか，ほかにちゃんといい本があるところは，そういう本を読んでくださいと。自分がそんなに詳しくもないっていうのもありますが。

中島：教科書でありながらポリシーが明確っていうところがおもしろいですよね。教科書を目指すとしたら，好き嫌い抜きでまんべんなく入れる必要があると思うんですが，そういう無理をしているような部分がなくて，全体的にすっきりしていると思いました。

山本：もう一つ言えば，僕が好きじゃないものは入れてないです。Webサービスの話をするんだったら本当はSOAPやWS-*（注3）を詳しく書くべきかもしれないですが，一切そういうことは書いていない（笑⁠）⁠。

注2）

URIに変数を埋め込む方法の仕様案。

注3）

WS-SecurityやWS-Policyのような「WS-」で始まる仕様をWS-*と呼びます。

RESTとの出会い

中島：山本さんといえば「RESTの人」というイメージがあるのですが，お仕事の中でもずっとRESTを意識していらっしゃるんですか。

山本：いやそれが，会社に入って最初にやっていたのはSOAPの仕事なんです。WS-I（Web Services Interoperability Organization）という，SOAPの仕様が各社ばらばらだからみんなで集まって共通化する組織があって，そこで活動したりしていました。

そんな中，2004年頃にRESTを知って，これはすごくいいなと思ったんですけど，会社では全然相手にされませんでした。

中島：それはわかるような気がします。コンピュータの歴史から言ったらSOAPのほうが素直な発展だと思うんですよね。ソケットがあって，RPC（Remote Procedure Call，リモート呼び出し）になって，オブジェクト指向のMicrosoftのCOM（Component Object Model）とかああいう方向になって，それをそのままWebに載せたらSOAPになります。過去との連続性はありますから，SOAPのほうが古い人間にはまともな仕様に見えるんですよね。

山本：まずそもそもRESTは仕様じゃないので，論文だけ見てもWebサービスは作れないんですよ。対してSOAPは仕様なのでSOAPを使えばWebサービスは作れたんですよ。

Webは疎結合分散処理でできている

中島：RESTってやっぱり，メソッドが8つしかないとか，ちょっと異常ですよね。実際にやってみればRESTのほうがいいってわかると思うんですけど，論文を読んだ時点では「ええ!?」と思っちゃうところはあると思う。

最近流行りのNoSQLも同じようなところがありますね。やっぱりリレーショナルデータベースをやってきた人間からすると，まともな分散処理は2層コミットで密結合のプロトコルですよね。それと比べるとNoSQLはちょっとふざけてるのかっていう（笑⁠）⁠。Eventual Consistencyってすごい言葉だと思います。機嫌がいいと一致してることもあるけど，あまり頼りにしてはいけないっていうことでしょ（笑⁠）⁠。

山本：DNS（Domain Name System）も昔からそうだし。

中島：そうか。DNSもそうですね。

山本：あとはMy SQLのレプリケーションも基本そうなんです。レプリケーション先に結果が行くかどうかはリクエストを発行した時点ではわからない。それでもなんとかWebは動いてるんだからそれでいいんじゃないの？ っていう割り切りですよね。

中島：私はもともとは汎用機のCOBOLの世界で育った人間なので，そういうRESTとかNoSQLとか気持ち悪くてしょうがないっていう感性はどこか残っているんですよね。そういう疎結合の分散処理っていうのを見ると，蕁麻疹（じんましん）出そうな人の気持ちもわかります。一方で今やっていることはWebにベッタリですから，分裂しているようなところがありますね。

山本：でも二面性があると，どっちの気持ちがつつかれたかで技術が成功するかどうかわかったりするんじゃないですか？

中島：ああ，それは確かにそうかもしれません。センサーが2つあるからわかるっていうのはありますね。

山本：絶対こっちが筋がいいって思うんですね。

中島：RESTは，「⁠これはいい」っていうセンサーと「気持ち悪い」っていうセンサーが両方反応したので，これはいけるんじゃないかという気がしました。ブログにもいくつか記事を書いています（注4⁠）⁠。

山本：2005年ごろですよね。そのころはRESTというキーワードがあれば何でも読んでましたので，essaさんのエントリも熟読していました。今の言葉で言い直すとURIのアドレス可能性について書かれていたと思います。Web上にあるものは何でも同定できて参照できると。Googleなどの検索サービスもこの前提で作られています。

中島：そうですね。URIをコピー＆ペーストできるっていうのがとても重要なんですよね。

山本：基幹系のシステムだったら何月何日のイベントの売上のここの部分っていうのをURIでがっちり指定できると後から拡張できるシステムを作るときにすごく作りやすくなっているはずなんですよ。

中島：Application state…なんでしたっけ？

山本：Hypermedia as the engine of application state。アプリケーションエンジンとしてのハイパーメディアですね。

注4）

「REST=コミュニケーション指向―アンカテ」