RESTful な URI の設計

REST で設計する際に気をつけなければいけないところはいくつもあるのですが、ここでは主に URI の設計について解説します。

URI には名詞を使う

URI はリソースの ID です。リソースの説明時に書きましたが、これは名詞であるべきです。たとえば、東京地方の天気予報リソースの名前が「東京の天気予報」ではなく「東京の天気予報を取得する」だったとしたらどうでしょうか。当たり前のようですが、すごく違和感がありますよね。

同じことが URI にも言えます。次の二つの URI のうち、どちらが良いと思いますか?

• http://example.com/getWeather?area=tokyo
• http://example.com/weather/tokyo

前者の雰囲気は「東京の天気予報を取得する」そのものですね。それに対して後者の雰囲気は「東京の天気予報」です。このようにリソースの名前、すなわち URI は名詞であるように設計すべきです。

GET の濫用

まず悪い例を見てみましょう。blog の記事を削除するときに以下のような操作をするとします。オペレーションが削除であることは action パラメータで指定して、削除する記事は id パラメータで指定しています。

GET /blogService?action=delete&id=332 HTTP/1.1

この方式の問題点は二つあります。一つは前項で説明したとおり、URI が名詞になっていない点です。

もう一つの問題は GET メソッドに記事を削除するという副作用を与えている点です。GET の重要な性質としてリソースに副作用を与えないということがありました。しかし、この URI を GET をすると、URI が指定するリソースが削除されてしまいます。これはセキュリティ上重大な欠陥となる可能性が強いHTTP の誤用です。

REST のためのフレームワーク

現在主流の Web アプリケーションフレームワークでは、上記のような REST 的にきれいな URI を実現するのは難しい場合が多いでしょう。Apache のmod_rewrite モジュールを使用して URI を無理矢理書き換える方法もあります
が、場当たり的解決となるのは否めません。

一方で、REST が Web サービスのためのアーキテクチャスタイルとして評価されるにつれて、REST をサポートするフレームワークが登場してきています。たとば Java では Restlet というプロジェクトが、また Ruby on Rails ではバージョン 1.2 以降 RESTful な Web アプリケーションが簡単に実装できる機能が次々と追加されています。今後はこういったフレームワークが次々と登場し進化していくでしょう。

まとめ

REST は Web アプリケーション、そして Web サービスのためのアーキテクチャスタイルです。REST スタイルを念頭に Web アプリケーションを設計・開発すると、Web ベースのシステムが本来持っている能力を十分に発揮することができるでしょう。特にスケーラビリティを重視した Web アプリケーションを開発するための必須スキルとなると考えられます。