RESTとURL設計の重要さを理解して「キレイなエンジニア」を目指す！

こんにちは、@kukoです。
今日は私の苦手なRESTの話をしますね。

はじめに

Rails1系から2系に上がった時に、頭を悩ませたのがRESTでした。

宗教じみてるし、なんか設定も複雑でやることが増えたような気がして、なかなかお友達になれない。

しかし、RoRのアプリを作っていくにあたって、どうしてもさけては通れない道でした。

私と同じように悩める方がいたらぜひ参考にして欲しくて、

RESTとは何か。
URLはどうあるべきか。

の、とっかかりとなる話をしたいと思います。

RESTとは

「RESTとは、ウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつである」

そんなこと言われても困ってしまいますよね。。

RESTは「リソース」を扱うための考え方であり、 URLというのは特定のリソースを指し示しているのです。

リソースとリソースの操作

RESTを考えるときによく出てくるのが「リソース」という単語です。

「リソース」とは、例えば掲示板があったとしたら、
掲示板の大元の書き込みであったり、
掲示板につけられたコメントのことであったり、
もしくは添付されたファイルや画像であったり、
そんなひとつの「情報」として扱えるものを指しています。

RESTの考え方では、リソースはそれぞれ固有のURLを持っています。

/bbs/3/comments/7

例えば、これは、id3の掲示板につけられたコメントの1つを指し示すURLです。

そしてそのURLに対して、「何をするのか」、それを「GET」「POST」「PUT」「DELETE」という4種類のHTTPのメソッドで操作をするのです。

URLはメソッド(動作)をあらわさず、メソッドはHTTPメソッドが対応します。
これがRESTの原則です。

古いRailsではactionがURLに入っていましたが、これは先ほど説明した「URLはリソースを指し示す名詞であるべき」という原則とは違いますね。

きちんとしたRESTでは、アクション名はURLに出るべきではないのです。 なぜなら、アクション名は動詞であり、URLはリソースを表すため、名詞であるべきだからです。

URLとメソッド名のギャップ

少し実装の話に踏み込みますと、設計はURL設計から始めると良いです。 キレイなURLが作れれば、コントローラーの実装で悩むことも少なくなるでしょう。

気をつけたいのはI/Fのレイヤーと実装のレイヤーでギャップがある場合です。

I/Fのレイヤーでは

「何を」= URL = リソース
「どうする」=HTTPメソッド

であらわします。
たとえば、先ほどの掲示板bbs/3にお気に入りの星をつけたい場合、RESTfullに書くなら

bbs/3/stars

というURLにPOSTリクエストを送ります。ここで、bbs/3/stars/addや、bbs/3/add_starにしないのは、 URLは名詞であるという前提からです。
考え方としては「starをcreateする」と考えてください。

これに対して、実装のレイヤーでは

「何を」＝主としてコントローラ名、補助的にアクション名
「どうする」＝アクション名

となるので
BbsControllerのadd_starがアクション呼ばれるようにするかもしれません。
(もし複雑だったらBbsStarsControllerのaddメソッドにするかもしれませんが)

どうでしょうか。このとおり、この２つのレイヤーの間には少しギャップがありますが、この２つのレイヤーの構造を意識して、 RESTっぽいURL設計はどうあるべきかを考えて設計すると良いでしょう。


少しはRESTとお友達になれそうですか？^^