『基礎Ruby on Rails』の原稿を書いているとき、Rails 1.2の目玉であるRESTをどう位置づけるかで悩みました。

本当にRailsがRESTに向かって進むのであれば、本書でもRESTを前面に押し出して書くべきではないかと。

結論的には、最後の9章をRESTに充て、8章までに少しずつ作ってきたサンプルアプリケーションを一気にRESTで書き直す、という構成にしました。

9章がプログラムの機械的な書き換えの話に終始してしまい読み物としてつまらなくなったという反省はありますが、悪くない決断であったと今でも思っています。

長くWeb開発をやってきた方々にとっては、MVCアーキテクチャの考え方はすっと腑に落ちるものであるかもしれませんが、初心者にとっては結構難しいものです。一言で言えば、抽象度が高いのです。そこにRESTという層が追加されると、さらに抽象度が高まって難解になります。

それでは、そもそもRuby on Railsを使うことがなぜそんなに嬉しいのか、ということになりかねません。

CGIプログラムやPHPスクリプトの場合、URL（パラメータ部分を除いた本体）とサーバサイドのプログラムがだいたい1対1に対応します。基本的にURLはサーバのファイルシステムにおける特定のパスを指しているのです。

しかし、RailsのMVCアーキテクチャには「ルーティング」という仕組みがあって、URLのパターンから「アクション」が特定されて、実行されます。CGIプログラムやPHPスクリプトの場合には明確に想像できた「HTTPリクエストが処理される場所」が分かりにくくなります。

それでも、Rails 1.1までの非RESTな世界では、URLにアクションの概念が含まれていました。ID=99の会員を削除するURLは /members/destroy/99 でした。しかし、RESTfulな世界では /members/99 というURLになります。このURLに対してHTTPのDELETEメソッドでリクエストするわけです。URLからアクションの概念が排除されています。

シンプルで美しい世界ですが、この美しさを堪能するためには、多少の素養と経験が必要です。

また、RESTの世界が美しくかつ実用的であることを示すには、説明する側にとっても準備が必要です。

少なくとも当時の私にはその準備ができていませんでした。
--
黒田努