濱野智史さんの『アーキテクチャの生態系』を読んでいる途中なのですが、この「アーキテクチャ」の肯定的な捉え方に、RailsとRESTの関係が思い起こされたのでメモを。

濱野さんによる『アーキテクチャの生態系』の紹介はこちら。

アーキテクチャって？

ここで呼ばれている「アーキテクチャ」とは、ローレンス・レッシグ『CODE』で説明されていたものです（最近はver. 2.0が出ています）。

レッシグさんは、人の行動や社会秩序をコントロールするためには、４つの方法があると言っています。それは、規範（慣習）、法律、市場、そしてアーキテクチャです。たとえばタバコを吸わせないように人の行動をコントロールするためには、これら４つの方法をどのように使えるでしょうか。

規範（慣習）

人の行動はマナーのような規範で制約することができます。分煙という規範は喫煙者に制約を与えます。もしくは「煙草は体に悪い」という言説を広めることによって（慣習）も制約条件になり得ます。

法律

人の行動は法律によってコントロールされるというのは理解しやすいと思います。たとえば「煙草は６０歳を過ぎてから」と法律で決まれば、喫煙者（< 60歳）に制約を与える事になります。

市場

市場もコントロールに使える一手段です。煙草の値段が10倍くらい（3000円とか）になれば、煙草をやめざるを得ない人が多くなります。

アーキテクチャ

アーキテクチャはそのもの（煙草）に手を加える方法です。上３つの方法は、制約を受けるとはいえ完全ではありません。規範や法律は破ればいいし、お金があったら市場による制約もあまり受けません。しかし煙草そのものに1本吸いきると確実に嘔吐するという薬品が含まれていたら（極端ですが）、煙草も吸えなくなります。この薬品を含ませるという実装がアーキテクチャです。

レッシグさんは、上３つの規制が完全でなかった（回避しようと思えばできる）ために、創造性が発揮される余地があったとして、DRMやコピーコントロールなどの完全な規制技術を批判するわけですが、濱野さんはアーキテクチャの「いちいち価値観やルールを内面化する必要がない」「人を無意識のうちに操作できる」という特徴を積極的に活用できるのはないかとしています。

アーキテクチャを使って、「よりよい」ことに使えるのではないか、と。

Rails = 「アーキテクチャ」？

本書ではニコニコ動画やグーグル、Winnyなど、どちらかと言えば提供されているサービスについて論じられていますが、このサービスを構築するための「フレームワーク」というアーキテクチャも、同じように「よりよい」ことを強制するために使うことができそうです。

ここでの「よりよい」ことが何かがとても難しいですが、たとえばIETFのRFCなどの「標準化」は、基本的な部分のみに制約を与えて、混乱を防ぐために機能するもので、守ったほうがよいとされるものです。
このRFCの「標準」設計はレッシグさんの言う規範にあたります。リクエストされたファイルがサーバ上になければ、人間に「ファイルが見つかりません」と表示させるだけでなく、HTTPステータスを404にしたり、ファイルの位置が今後変わるのであれば、301でリダイレクトしたり。この標準にみんなが乗ることによって、例えばRSSリーダーなどの開発者はコンテンツ（ボディ）を解析することなく、リソースの特定を行うことができます。しかしこれを守らなかったところで罰はありません。現に携帯会社のメールアドレスがRFCに準拠していないという話もあります。

そこでこのような設計をさせるために、フレームワークというアーキテクチャを利用することができます。たとえば、フレームワークに実装されているメールアドレスのvalidationメソッドでは、アカウント部分の最後に.（ドット）に入っていたらエラーを出すようにするなど。
フレームワーク自体にRFCなどを反映したものを実装することは、濱野さんのいう「いちいち価値観やルールを内面化する必要がない」「人を無意識のうちに操作できる」というアーキテクチャの特性をある意味ポジティブに使えるのではないでしょうか（それによって開発コストが増えればあまり意味ないですが）。

REST原則の実践としてのRails

Railsは2.0になってよりRESTfulになりました。

RESTfulなサービスを作ることは開発者にとって、他のサービスにとってメリットがありますが、その必要性は説明しづらいものがあります。それは、たとえば、XSS対策の必要性が、「被害が出る」という非常にわかりやすい尺度で説明できるのに対し、サービスをRESTfulにすることの必要性は主観的（「便利だよ」とか）・哲学的な理由（「そもそもHTTPの設計は云々」）でしか説明できないところにあります。
RESTfulなサービスを作ることがそこまで難しくなければ、哲学への共感や利便性を求めるほうが、手間より勝って実装するという流れが生まれるのかもしれませんが、実際はRESTfulにサービスを作ることは、そこまで簡単なことではありません。

しかしRailsでは（比較的）簡単にRESTfulなサービスを作れるような「設計」にしています。極端な話、開発者がRESTを意識せずとも、何行かのコードを加えることによって実現できてしまうほどです。

このような（サービスとしての）アーキテクチャを作るための（フレームワークとしての）アーキテクチャに、ある種の思想が反映されていることは、その思想を拡げるためにもっとも有効な手段なのかもしれません。RESTのメリットを説明するよりも、REST原則に沿ったアプリケーション構築をさせる設計、そしてActiveResourceのような実際に利便性の提示するもの。これらによってRailsはインターネットを「よりよい」ものにさせる「アーキテクチャ」として機能しているように思えます。